I've had similar question to yours last days, and here is what I found:
Transaction is not being created, but synchronisation (and Hibernate session) is created. So because method is annotated with @Transactional, Spring crates for the whole method's duraiton a Hibernate session. Upon creation, Hibernate reserves a DB connection from the pool.

Because the setting propagation is NEVER, there is no transaction created (no BEGIN issued).

So the mistake we made is to think that transaction and Sring synchronisation have the same scope. They do not, and because Hibernate is used, some extra resources might get tied.

I suggest extra read here: https://github.com/spring-projects/spring-framework/issues/31209 User had similar problem, and there are actually some settings suggested for hibernate to not reserve a connection without transaction active. (like DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT)

There are other consequences: because hibernate session is active, its L1 cache is also enabled. So any queries made via JpaRepository or other Hibernate beans will be cached (even without transaction). This can add another layer of problems (which I have met personally).

Suggestion for readers: if you can, just drop hibernate (spring-data-jpa) in favour for JDBC (spring-data-jdbc). I prefer to get what I see and not be surprised by some framework magic.