In my current setup ( a java enterprise application) , we have a ActiveMQ adapter for log4j which pushes of all the Error and Warning messages to an MQ Series Queue asynchronously. There is a consumer which reads the messages off the queue and processes them and writes results to a SQL database. we have a simple webapp that allows people to download this data as CSV files , load it into Excel and do analysis.
I do not doubt that projects like NSQ will have a hard time securing adoption in Tibco shops, because Tibco is a sort of guaranteed-employment scheme for its administrators. But the developers that work with these things tend to hate them (Tibco in particular tends never to work except in its one delicate production configuration, and projects routinely flatline because the bus goes down in the dev environment).
One thing I see a lot of in enterprise dev shops is that there tends to be a huge investment in a particular stack (J2EE, JMS, MQ, Struts, &c) and then once every other year a skunkworks project happens with some new system that deliberately uses a different stack. Last year, I saw a lot of Websockets and JMS. This year, maybe it'll be decent message queues.
I do think that messaging solutions at this point are nearly indistinguishable from each other.
For the record... NSQ is a generic messaging platform and is data format agnostic, there is nothing specific about metrics collection (it was just my contrived example).