Done a fair bit of CLR.

1) TiffPageCount: We have a java-based tiff viewer to display scanned images in our main web site. For multi-page tiff files it requires a count of the pages as well as the location of the document. Our web team was struggling to get a count and I just made a little 10 line CLR that calls system.imaging to get it. Super easy to code but not the best use of a database server.

2) HUGE XML export: We needed to generate a very large XML file for a client - over 200MB. None of the SQL Server tools could do it. VB.net via CLR to the rescue. Personally, I doubt the client ever manages to import the file - but I delivered it.

3) US Standard Claim Forms EDI (X12 - 837): This is basically a full-featured app called from SQLCLR udf's. It manages queueing up records to be added to a file, generates the unencrypted file, encrypts the file using a public key stored in a table (gpg), and can send the encrypted file via FTP, email, or simple network storage. It reports on the entire process and is smart enough to tell users when a record doesn't meet the requirements to send. You can buy X12 exporters but they are VERY expensive and still require a lot of work to set up. All told - for maybe $25k worth of my time I built my employer an app that would have cost them at least $250k to buy. Nope, I didn't get a bonus for it. haha

4) AP XML Feed Import: The Associated Press has an XML format that is too complex for Microsoft products to read. I wrote a VB.net CLR to parse it.

CLR has it's place and I know I've stretched it a little farther than I should. Sometimes what's expedient just takes precedence over what "should" be done.