The first thing that stands out for me is that there is no single "killer" point ...

The killer points for me in favour of stored procedures over embedded SQL are:

• Relational logic and database design is hard to master.

  A good DBA (a rare breed), can save the company their salary many times over. Very few general programmers become really adept and DB design.

• Applications need only the results, not how to obtain them.

  DB design transcends applications for all but the most trivial. A DBA can provide cross-application overview and arbitrate between their disparate requirements. Application programmers are usually to caught up in their current applications requirements to step back and subjugate their perception of their applications needs in favour of another applications with such arbitration.

  Isolating your DB design from your applications, and vice versa, is a sound application of the decoupling principle at so many levels. New applications come on line that require changes to the DB schema. Other applications should not have to change to accommodate this. The stored procedures are modified to account for the new schema and existing applications continue to run without change.

• Business code and data should live together and be application independent.

  Tax rates, depreciation terms and a whole gamut of other typical business calculations, rules and logic live outside of the applications remit, and are subject to change by government edicts and legislation.

  When they change, they change across the board for all affected applications. Changes should be implemented and tested once, not in every application.

• You do not realise the true benefits of a RDBMS until all your business data exists in a single database.

  It is only once it is possible to perform relational logic across the entire range of company data assets that they really begin to earn their keep.

  Warehousing solutions where the data from individual databases is replicated wholesale into secondary conglomerations miss opportunities for ad-hoc queries that the conglomeration process does not support.

  Similarly, warehousing that attempts to perform cross DB boundary searches via meta-data and meta searching are rarely, if ever, capable of keeping up with changes and accommodating speculative ad-hoc queries. There is usually a fairly substantial delay between the notion of a cross-DB connection query being useful and it becoming available; and a not inconsiderable expense in making it available, which requires a costed business case to be made before budget can be allocated. Those delays, costs and red-tape suppress discovery.

No web programmer worth his salt would advocate the mixing of Perl and HTML. Why advocate the mixing of Perl and SQL.

The obligatory analogy. GP's diagnose, prescribe and manage year on year health care, but they defer specialist treatment to specialists. Eye, brain, heart specialists etc. etc.