I did not get an answer to my reaction on my comments on your original points yet, so here some additional comments.

>- They provide an application/client-agnostic API for accessing the database.

Which can be both an advantage or disadvantage depending from which angle you look at it. It depends on what you wish for. This in itself list any technical advantages.

>- Having an application-agnostic API for the database can really become beneficial in a corporate environment with several applications and developer teams.

Again, this in itself does not have technical advantages. In this case it only serves the purpose to protect the database from the developers making illegal or errant calls to the database. It might limit the developers having to do with what is provided and they have to workarround certain issues. In other cases they have to make requests for new SPs to be able to generate that new report.

>- If I had a dime for every time an I.T. manager breathed a sigh of relief when I told him/her that something could be added/changed/fixed simply by tweaking a stored proc (as opposed to having to update an application DLL), I'd have plenty of dimes.

Again, no technical reasons here, rather anadoctical experience. The described percieved advantage is not limited to SPs.

>- I can abstract out and establish an API and build stored procs independantly of the application, and in many instances can make changes without disrupting the development environment

Again this is not limited to SPs. Meta data and remote views can be defined out of the application.

>- The new tools for building custom database unit tests in Visual Studio Team Edition for Database Professionals are outstanding. (If anyone is interested in building unit tests for stored procs, you HAVE to look at this product. It is fantastic).

Again, I don't see an advantage for SPs here. Not sure why you think you cannot unittest remote views, queries or data-access layer.

>- It's much more difficult for a DBA to manage database code if it's residing inside application logic

If that is an requirement or even an convern then SPs might be a good idea. However when the vendor is the owner of the database I don't see what the DBA has to manage.

>- SQL 2005 contains many new language features that are best utilized inside stored procs.

Which features are usable in SPS and not in SQL scripts ??

>As I've said before, I use them as a strong starting point, unless there are good reasons for not doing so. In general, I believe that all external access to a database should occur through stored procs.

I've not seen any technical reasons above to support this standpoint. However I've gotten the impression you mainly deal with situations where the client is owner of the database and a DBA is in place to have tight control over all aspects of the database. In that limited scope of database development SPs might be a required starting point from a clients perspective. For all other cases I've not seen one convincing technical advantage of SPs over dynamic SPT.

>Clients WANT me to use stored procs. I work with at least a few new I.T. teams each year, and I can't think of one that didn't want to use them. And when the ultimate decision is left to me, I use them on a regular basis.

Which supports my impression above, however this in itself does say nothing about all other types of applications where the vendor is in charge of the database, the database needs to be queried ad-hoc (datawarehousing), or otherwise does not want to restrict itself by a database API implemented by SPs.

Walter,