it's based on my own experience and a dude from Oracle team. However, it's not hard to picture the downright performance impacts of two phase commits. As for changing use cases I am talking more about changing your design in way you could do the same thing with single commits. For example, in a project  I had the mandate to put a data in two databases each of which on an individual data source. One was live data and the other one was historical data good for book keeping and similar. That specific code point would be called a few hundred times in a second and two phase commit was not an option for me. Therefore, I had to register with the present transaction  manager and do the history part at the end of the first transaction and since I didn't want to lock things up for long a JMS queue was used. However, there was a chance that JMS would fail and the only remedy at the time was to dump the data in a local file which would be picked by a system health service later. My assumption at the time was that one of these would work, and if all failed I would be probably one of the guys in WTC buildings on 9/11.

In any events, there are small things that you can do to improve performance. For example, in the same project we opted to disable persistent transactions, and in our scenario it was an improvement. We also decided nested transactions are not for us and that made some performance difference too but to a smaller extent. Splitting logic into transactional units and non-transactional units also helped a lot but this should be done with extreme care.

In addition, I do agree with you that JTA has been smeared all over other J2EE services but at the same time many of these things work  great for vanilla applications. Crossing the vanilla line requires a little bit of thinkering here and there.