Shredding XML is hands down faster with SQLCLR and becoming more and more common in database work. Binary Serialization and deserialization of data with Service Broker is another great use for SQLCLR. A lot of people use XML for their SB messages which is bloated with definition attributes and elements. Passing a binary serialization of the message is faster because it is smaller.

I am not a fan of most CLR implementations I see people doing, I think there is usually a better way to handle certain processes, but if a process requires loop processing, CLR can be better at that kind of work. Whether or not it is considered to be Business Layer Logic or not depends a lot on the kind of business you are in and what may or may not be consuming the data. If a dozen applications need a complex calculation using CLR in SQL to provide that versus placing it middle tier makes a little more sense, the code is only in one place and you have a simplified deployment model there.

Smaller shops may accept SQLCLR for coding simplicity where TSQL has a slight advantage performance wise and they don't have a Jeff Moden or Sr. DBA that knows how to write TSQL to solve the problem. If the difference in perf is only a few hundred milliseconds, most people won't even care, which is a sad truth.