The key item here is the last line. Yes, I have many examples in my old ERP system where lots of stuff needs to happen to multiple things as a part of a business transaction. I'm not entirely sure that it all needs to be a part of an actual transaction, see below, but for the moment lets assume that it does.
You don't say where the info for all of this comes from, but let's assume that there is some set of temp-tables, perhaps a PDS, that you fill and validate either based on user input or interaction with a data stream or whatever. Or, perhaps this is a previously persisted order that came from the database, was modified, and now needs to be put back. The logic to do that is going to be walking through, either using something like save-changes or explicitly creating buffers and doing buffer copy. OK, where in there do you need to empty any temp-tables? After you are done, when the transaction is over, then you may want to empty the TT to get a fresh start, but why during the transaction itself? I don't see anything in that logic which implies the need to empty a TT.
As for the transaction scope, there is a tendency for ABLers to equate business transaction with DB transaction. After all, this seems to be a natural way to insure atomic purity. The problem with this assumption in modern systems is that the parts of the business transaction may be on different servers. E.g., the basic transaction could be happening in an OP service, but updating the item information could be in an Inventory service and the AR parts might be in an AR service. There are technologies for distributed transactions, but that is just as bad an idea as stateful AppServers and locked agents. One may avoid inconsistencies in the data, but at the expense of driving the system to its knees. This leads to an architecture where there are async messages, exception messages, and rollback logic instead of relying on DB transactions. Point being, with reliable messaging, it is going to work as planned nearly all of the time so the exception handling will be very rarely invoked. It is not quite so tidy as wrapping it all in a DB transaction, but the advantages can be substantial.
I am reminded of a customer some years back who used to get a check once a month that would pay off as many as 7000 invoices (many branch stores). Because each invoice touched multiple tables, this meant a single transaction that touched something near 30,000 records ... all locked, of course ... which blew my idea of reasonable levels of -L. I handled this at the time by just bumping -L for that site, but in retrospect I realize that one could have restructured it into a restartable process and kept the transaction to a single invoice. In your logic above, a few flags would tell you whether or not you had completed a given step and one could then make each step its own DB transaction, but the process would be restartable if aborted in the middle.