Why using BTM
There are two different arguments here:
Why would I need a transaction manager ?
If you either use two databases (or more) in your application or you use both a database and JMS then you need a transaction manager. Some people will argue that you can do without one even if you fall in on of those two cases. They are true: it is possible to have a transaction span two resources (like JMS and JDBC) by writing so-called idempotent methods manipulating these resources and some simple error recovery logic.
The fact is that it is harder to write idempotent methods (when it is possible at all) and you also have to write some recovery logic to handle crash cases. It is more or less easy to write code that makes sure the information gets registered at least once. Idempotent methods make sure that in case they got called twice (because of a retrial after a crash) data will be safe anyway.
Why would you have to accept those constraints when you can get free of them ? And why would you have to be careful about low-level logic in your code when you can delegate it to an component specialized in this task ?
Would you write your own web framework or your own ORM nowadays ? Neither would I. It is the transaction manager's job to make sure consistency is kept across multiple resources, not yours.
Why using BTM and not insert another TM here ?
In short: because it is complete and easy to use.
BTM has been tailored to support only the most common scenarios: XA with JDBC and / or JMS. It's internal logic is kept as simple as possible to only support them. On the other hand, great care has been taken to make those scenarios working as best and as easily as possible. BTM also fully supports crash recovery thanks to its disk logger.
You might need more than what BTM proposes, like JCA Connectors support or JTS. In that case you should look at other available products.