Leaving aside the conflict of interest here ("EDA bad, workflows good, buy DBOS workflows"), this is a significant straw man. The author more or less picked the worst example of event-driven architecture, then says, "See? It's bad."
The flow of reserve item -> check credit -> process payment -> fulfill order is actually a pretty synchronous process. There's no reason to make that event-driven unless you actually need it.
Should people reach for event-driven first? No, almost certainly not. Is this something that should be event-driven? Not as presented.
But if you imagine that the process becomes "process payment -> [5 other things]," such as fulfilling order, sending receipts, updating analytics, initiating fraud detection... those are all things that should be done in parallel and none of them need to know about the others, nor does the payments system need to know about them. _That_ is a better use-case for EDA that justifies the additional complexity and cost that the author is warning about.
