While reading the PDO documentation, they state:
When the script ends or when a connection is about to be closed, if you have an outstanding transaction, PDO will automatically roll it back. This is a safety measure to help avoid inconsistency in the cases where the script terminates unexpectedly--if you didn't explicitly commit the transaction, then it is assumed that something went awry, so the rollback is performed for the safety of your data.
Today, when the PHP script ends, the Transaction objects destructor will be called, thus forcing a clean autocommit: this is a bad practice in most cases.
Ideally, when the shutdown handler time comes, the non finished transactions should not commit but fail instead. A non commited transaction at script end means that a poorly developed portion of the code or a logic error happened.
Today, I spent 2 hours on debugging transactions, because of Commerce pessimistic locking which actually create one of them as soon as you load at least one order: this means that everything that happens on the site will be isolated in this transaction. They never release it, considering than they are the own of the order, the only case it can be released is if you save it or reset the controller cache. If anything goes wrong and make it fail, the whole page runtime will be a ghost and may disapear (and this also may cause extra cache miss). This is an example, not a bug report, nevertheless, this is a perfect exemple of a terrible transaction usage which can cause serious trouble.
If the database system was able to, at least, extra verbose critical level errors when the shutdown handlers come and transactions are not commited properly, this kind of code in contrib (and potentially in core too) would be easily spotted and naturally fixed as soon as it exists. Best case scenario would be to let the transaction rollback instead, but the critical watchdog messages (even with transaction commit) would be a great help for all developers.
Important: I am NOT saying we should change the auto commit policy on object destruct and change DX, I'm only speaking about the shutdown exception of this policy.