I am sure that there are other various utility ways to do things in CLR beyond what I have provided above. I haven't had much need for it beyond DBA related tasks that are easier done in CLR than in TSQL, and as you say, at a certain point a external application just makes more sense to me. However, there are those out there who would opt for the simplicity of solving a problem in CLR over the required TSQL to solve the same problem, even if there is a slight hit to performance.
One area I didn't cover in my first post was the power of using CLR Aggregates for things like median/mode/FFT (Fast Fourier Transformation) calculations. However, these have a very specific uses and very specific applications. They aren't need in 95% of database applications. There is a trade off for having them in CLR and that is, you run more CPU utilization on the database server, but you save the cost of moving large volumes of data over the network to the app to do the same calculation.
I can definately see potential for where CLR can solve complex problems, but I rarely see CLR used in this manner. It is like XML, and cursors, when applied properly, it can be very powerful to solve complex problems, but it is easily misused. A guy at work today made the statement, "When all you have is a hammer, then every problem becomes a nail." He was referring to a process in our Oracle environment, where years ago someone wrote a process that was better solved another way. However, the developer then only had knowledge of one way to do things, and the process built really reflect that. I see .NET programmers making this same kind of mistake today in SQL Server, where they will write CLR procedures that use nested datareaders (cursor anyone) to do what could easily be done in a single set based operation with TSQL alone.
I personally have written a lot of CLR code inside SQL Server, just to figure it out, and learn the ins and outs for where it is a good fit or not. For reference, I have little to no CLR running inside a production SQL Server. I refuse to write it off as a possible solution outright, but I would need a good reason to implement it in production use.