if you would use "standard" audit-trail functionality you would create a before image and an after image. Going back would then simply be an issue of reverting to the before image
It is correct that the microflow does something like your describing when an exception occures. It reverts all the changes that have been done in the microflow.
See this wiki page : https://world.mendix.com/pages/releaseview.action?pageId=3736919 (bottom of the page)
However influencing transactions and the context isn't as easy as calling only a single rollback if you want to revert all changes. This causes all of your objects to be unavailable to the application. All objects from the same type as the objects you changed in your flow can't be retrieved any more and all your retrieve actions keep waiting forever.
This bug I am describing is one you will be seeing verry often when you start working with transactions.
The most important thing is that you always start the same amount of transactions as you end or rollback.
So if you want to do a rollback you also have to do a start transaction at the begin of the flow, an rollback when you want to revert the changes and an endtransaction at the end of the flow (when executed correctly)
Another thing, you should not use to many transactions the more transactions you start how bigger the load becomes for the datebase (you might remember the postgres out of shared memory exceptions) database exceptions are usually caused by using custom transactions (or errorhandling, which creates a new transaction) the wrong way or to often.
This are only a few of the problems I have ran into and I can think of in a few minutes. There are many more bugs and strange cases you have to think of.
Transactions can be verry usefull, but can cause a lot of problems. So if you suddenly get some strange exceptions or behaviour in your application, start debugging and counting your transaction calls.