String-manipulation intensive operations are a prime example where the CLR will most likely kick T-SQL's rear end. I'm currently in the process of running some tests on the SQL 2K5 Express June CTP that perform millions of string manipulations in T-SQL as well as in a CLR UDF. So far T-SQL string manipulations can't even compare to a .NET StringBuilder in a UDF.

Another thing is bit-level manipulations. Ever try to encrypt or encode a string of bits using T-SQL? If you actually succeed, it will bring your SQL Server to a crawl. The CLR can handle extensive bit level manipulations much better than T-SQL.

Finally, there is a lot of O/S-level functionality you might want to call from within a T-SQL script. You might want to call the Windows Crypto API, or call the O/S and ask how much free disk space you have. COM is overkill for these type tasks.

That's the problem with oversimplified examples, like "Hello World". If all you're doing is returning the string "Hello World" you'd be better off with T-SQL. If you're trying to do something that requires a lot of string manipulation, excessive looping, Windows API calls, extensive bit-level manipulations, etc., you'd do well to look at UDF's.