To some extend I disagree.

CLR for SQL-Server is a kludge - a sensible kludge, because it provides extended functionality, albeit with a performance penalty incurred by the very nature of this kludge, at a much lower development cost for MS than providing it without the kludge (by a massive extension to the T-SQL language, with little or no prospect of getting the standards committees to support it for SQL, and probably several years of research and looking at design options before it could get under way) would have cost (and probably a much earlier release date too). But claiming that CLR never has a performance penalty, or that providing a CLR mechanism rather than putting a fully functional user-defined type/class capacity inside the data engine and in the T-SQL language would not be less of a kludge and deliver better performance for many things that currently have to be done with CLR is just crazy.

Of course there's nothing kludgy about using CLR to solve a problem that can't be done in T-SQL - the kludge is what MS did, not what its users are doing. Since MS has provided no other method of doing it, the users have no choice. Nor is there anything kludgy about using CLR for something that can be done in T-SQL in cases where CLR will deliver better performance (but be careful - some people have been quite surprised when they've done performance measurements).