You're missing the point. You don't need to rollback past transactions that make unwanted changes to the contract state. If you have the ability to update a contract, you can add whatever functionality you need to undo a given state transition. You invoke the new function with a new transaction. The old transactions don't suddenly not happen. Your new transaction simply reverses the state changes, making it as if they hadn't affected the state at all.

It's likely that you aren't considering this possibility because, of course, the average token contract does not do this. It would be a significant trust violation if a contract controller circumnavigated the need for signature checking or allowance setting in order to perform arbitrary token transfers. That does *not* mean the possibility for it to be done does not exist.

At the end of the day, token balances are just key-values in the contract storage, and how those values are changed is enforced at the contract code level. That code can say whatever its controller wants it to say, and if they deploy with the ability to update, they can alter the code as necessary in the future. Token contracts are extremely simply, easy to audit, and so are seldom deployed to be updateable.

To summarize, "irrevocable outcome" is not a fundamental trait of a smart contract application. It is a choice at the code level, with tradeoffs, which can be adapted to suit the application.