Personally, I think that SQL Server (set based RDBMS) is a fairly focused product. Yes, SQL in all its flavors is a language, but it have a specific purpose. It has lots of add-ons, but that's primarily what they are (add-ons that try and keep up with the other guy and ease integration with other functions)

It seems that SQL CLR is just a way to create more add-ons. Do you want RegEx? CLR! Do you want specialized encryption and hashing algorythms? CLR! Do you want to completely interface with the file system? CLR! Do you want to pump data into SQL Server? SSIS, BCP, CLR, etc Do you want to perform message queueing? Service Broker! By giving us SQL CLR it's opened the door to do a ton of things that we would have to wait for Microsoft to code.

Is it easy for a database developer to create SQL CLR procs correctly and efficiently...not really. It's a different animal. So is SSIS. (which I hate with a passion!) Will a web programmer code up a SQL CLR proc correctly and efficiently? Probably not, since there are SQL Server constraints and constructs that might not be readily known/understood.

It takes somebody willing to bridge a few worlds (DBA, SysAdmin, SQL developer, .net programmer). When that person does it though, it can produce a very nice solution to a problem.

Let's face it, when Microsoft added first class xml support to SQL Server it was welcomed. We could have done it all ourselves with SQL CLR though (we != me).

I think the title of Phil's editorial was definitely intended to create some conversation. I don't know if Microsoft "went wrong". I think it was mostly just a mismatch between marketing promises and expectations and reality.

Just my .02.