In The Message Consumer Rollback Pattern, I implied that a message should usually be consumed from a queue in a transaction. In this case, one advantage is that if the processing of a valid message fails, it can be rolled back onto the queue (instead of onto a standby queue). In the comments, Euxx (Eugene Kuleshov?) argues against this in his own blog posting, Sometimes transactions are not your friends. His main motivation against using transactions seems to be everyone's favorite whipping boy, performance.
The point of using transactions to consume messages is to ensure that messages are not lost, that all of the processing of a message completes successfully before permanently removing the message from the channel. So the questions are: What's the risk of losing messages? And what're the consequences?
Transactions definitely add overhead, as does persistence, security, and a host of other quality of service capabilities which help ensure a system functions correctly even in the presence of adverse conditions (such as crashing when a task is half-completed). You don't need security (or locks on your doors) if you know that no one will ever try to do something they're not supposed to, and you don't need transactions if you know that all your tasks once begun will always complete successfully. Transactions, like these other QoS capabilities, are insurance against failure; every success pays a small tax which more than pays for itself if and when failure occurs.
Like with any insurance, you have to ask yourself: Is it worth the cost? Namely: How likely or often will failure occur, how negative can its impact be, and is the overhead on the cases that turn out to be successful worth it? If you knew which cases were likely to fail, those are the only ones that need the overhead. (That's why not all Internet traffic is SSL encrypted, only traffic containing private data.) So it's never as simple as saying transactions (or persistence, security, etc.) add too much overhead, systems run faster without them, so don't use them. Of course removing overhead improves performance, and you'll look like a genius, right up until a problem occurs which would've made the overhead worth it.