If the numbers hold true, you could actually use a separate database for each test, which could be hugely beneficial. It's way to easy to cause some unintended interaction between tests if sharing a db.
On the other hand I've seen quite a few bugs caught in testing exactly due to the lack of isolation between tests, because the same ones would have shown up in production...
This is easy in dynamic languages, really hard in in static languages.
And because you abstracted all your transaction logic away for the tests, your test result is not worth anything.
IMHO, there are only 2 ways to achieve proper database testing: 1) new db for each test (very slow) or delete all data from all tables before the test (ok for smaller projects) 2) tests do absolutely have no impact on other tests with the data they added/modified/dropped (very hard to achieve).
Edit: typo
It doesn't have to work in all corner cases, just the ones that matter to me.
The advantage of doing it this way is the tests run very fast - which is critical if you want developers to use them often.
However, if you add this behavior to an existing test suite you will likely have to fix a lot of tests assuming sequences will return predictable numbers, such as in automatically generated primary keys. Technically, these tests are already broken even if it is unlikely to see them fail.
We still use transaction rollback for most of our tests, but all tests are written with the assumption of existing data, to accommodate for the few tests that must commit their transactions (such as concurrency tests).
It also enables parallelization of test runs :)
And it also makes testing databases with limited transaction APIs (like DynamoDB) much easier.