But why would any of this matter? Your claim is that the application begins a transaction (a transactional method is the same thing) but does not want to acquire a Connection. I'll assert that this effects an extremely small population and I'll even go further to question the validity of this use case.

It's indeed intended for high-performance use cases only. The advantage of delaying the connection acquisition is that you reduce the time interval a connection is leased by any given transaction. This is desirable since the number of connections available for every front-end application is limited, especially when you auto-scale due to a sudden traffic spike. Therefore, the shorter the connection lease time, the more transactions can be accommodated in a time unit.

The application chooses to start a transaction. Why can't it simply choose to not start the transaction?

As a general rule, this is a very good approach. That's also why I said that we shouldn't change the default mechanism. My idea is to allow the user to explicitly choose to delay it until he really needs the connection.

this new setting should default to whatever hibernate.connection.autocommit is set to

That makes sense. But this is only applicable to DriverManagerConnectionProvider and c3p0 ConnectionProvider since it's not taken into consideration when we use an external DataSource.

IMO this really entails a whole new "Connection management" scheme where an auto-commit Connection is auto-released under the same circumstances as what we do under JTA transactions. That would be the logical continuation of your thought... which specific Connection is used is actually completely irrelevant and we could aggressively release the Connections back to the provider.

That would be desirable if database connections would support transaction multiplexing. However, even if the JTA specs demand it, in reality, even XA drivers don't always support it. To the day, I don't think there are many RDBMS capable of operating with multiple concurrent transactions on the same connection. For this reason, even if we aggressively release a connection on a RL transaction, the connection pool will most likely roll it back as illustrated by HikariCP source code.