Having recently read your reaction to "Logic in the Database", my impression is a few facts might be helpful. You wrote
"he made a case for placing a majority of the business rules and logic in the database"
The article (http://www.sqlsummit.com/articles/logicinthedatabase.htm) actually has a different message and it says:
"There is no single best solution for distributing the logic of a database application, and the choices are many."
"most importantly, databases don’t scale."
Scalability is a product of the system architect's skill. It's no longer a limitation of the technology. Consider these facts;
1. It's been 8 years since Microsoft demonstrated SQL Server processing 1 billion transactions in a day (11-14,000 tps).
2. The best performance on TPC-C leader is currently 3,210,540 transactions per minute (53,000+ tps).
3. UPS is doing 1.1 billion SQL transactions per hour on a federated DB2 database.
4. Verizon has an SQL Server database that's 50,747,000,000 rows.
"I can also tell you from experience that over time Ken’s theories on the advantages of this type of model will be proven wrong or at best cumbersome and clumsy."
Microsoft's choice to add the CLR to SQL Server 2005 was not risky business -- letting users embed classes in databases is not revolutionary.
Other SQL vendors (IBM, Informix, Oracle, Sybase) have been there and done that. They've shipped SQL servers that integrate the Java VM, support embedding Java classes in databases, Java stored procedures and UDFs, etc. It's mature technology that's shipped in product releases since 1997.
If this model of extensible databases had proven "wrong or at best cumbersome and clumsy", it's fooled the brain trust of the biggest database vendors. Microsoft isn't the only company integrating the CLR into their SQL servers. IBM and Oracle have done the same.