The problem is that the database is the bed-rock of modern applications.
If a web-server in a server farm has a memory leak due to dodgy code then an restart isn't a big deal.
If a database server has a memory leak then it affects everything sitting on top of it.
I don't have a problem with CLR code provided I have faith in the process of testing and auditing of the code to a standard where memory leaks aren't a problem. Apart form memory leaks I worry about garbage colletion in .NET getting rid of garbage slower than the functions that are creating it.
When a problem occurs in software the first port of call is the DBA because someone says "Oh, its a database problem" and with DBAs it seems to be guilty until prooven innocent.
As someone with a varied development background I notice that people use what they are comfortable with, so someone with limited experience is going to provide a solution using one tool. Someone with more experience will start to say "I will solve problem A using tool Z and problem B using tool Y because those are the most appropriate".
I worry that people who know C# will say "I can solve this set based problem far faster in C# than in T-SQL" and DBAs saying "I can solve this string manipulation problem using T-SQL far faster than in C#".
On the subject of delivering solutions I've seen too many solutions that were delivered on-time and on-budget that worked adequately at the time of installation but 6 months on they fall to bits. The emphasis was entirely on the time and budget constraint and not on the quality and durability constraint. No allowance was made for the cost in time and money of having to re-engineer a quick fix.