Do CLR triggers really represent the most popular usage of CLR in enterprise SQL Servers? If so, what on earth are they doing?

It was while I was listening to Michael Wang and Amit Shukla's interesting talk at the recent Tech Ed, 'Microsoft SQL Server 2008 Nine Months Post-Release: Best Practices and Lessons Learned' that I was brought sharply awake with a jolt. The screen showed the following:

Amit is Principal Group Program manager for the SQL Server team at Microsoft. He had been explaining how valuable the SQL Server team had found the Feature Usage reports and was urging us to enable their use.

The graph shows the number of objects per database (Enterprise edition Servers with >10GB data) based on 300 databases who have opted in to feature usage reports. I would then estimate from the graph that the original figures were roughly as follows:

Leaving to one side the surprisingly small size of these databases and the lack of primary key restraints in tables, I was surprised, firstly, at the poor take-up of CLR in general but also the high usage of CLR Triggers. When we think of CLR Triggers, we may think of Miles Trochesset's excellent CLR Trigger that registers UDxs in SQL Server when an assembly is created. However, I'd have thought that the most widespread use of CLR triggers would be for auditing purposes. You can implement both DML and DDL triggers to track changes in production databases and can even use generic CLR audit triggers that can be called from a number of different tables. The end result is a reasonably comprehensive auditing system based on CLR triggers that can be retro-fitted into existing databases. I can't think of any other uses for CLR triggers which can't be better served by ordinary triggers.

After the talk, I asked Amit if he knew what the triggers were being used for. He didn't, and couldn't know, from that source; but the SQL Server group at Microsoft would be interested to know more. Really, the above data just poses questions. What are CLR triggers being used for in production databases, and why choose CLR rather than TSQL for the triggers? Are we looking at a few production servers with a lot of CLR triggers or many production servers with around ten of them? How suitable is the CLR for this sort of usage? What do you think?