The point is that any tool that enhances productivity and promotes easily understandable code is the way forward.
CLR integration gives us programmers a very useful tool. Sure, if you can do it in T-SQL quickly in a way that mere mortals can understand go for it. And as I've said before if you can use a set based operation that's great. Unfortunately, I've had to resort to cursors in the past... Now, they are supported in T-SQL and they are very much my last resort..
So if I can write something quickly in C# that my team members understand or slowly in t-SQL using arcane statements, requiring the sacrifice of a goat which way should I go?
I had to look at a sproc recently... legacy code.. Only 400 or so lines... Shared it with my team - they couldn't understand how it worked. We proved it didn't work for several cases.
Rewrote it in t-SQL.. Took me two days... now it's supportable, testable and works. a mere 800 lines. But it would have taken less than a quarter of the time in c#
So, the sanctity of the data is important. But we have a duty to provide quick access to that data. Usually, T-SQL is the resource of first choice, but CLR will be the future.