The answer is, you model those as well and work out what to do. But it's more messy than you might think if you just model the first-order failure paths.
1. A misunderstanding of the business rules. In the flight example, you thought that were flights were cancellable, but actually the airline only offers nonrefundable seats.
2. System type errors, e.g. network outages.
If you get a type 1 failure, that's an error that gets ingested in your error monitoring service, and is a bug that needs to be fixed. If you get a type 2 failure, idempotent cancellation (which is necessary for this work) will eventually get you to your desired state. Either way, you shouldn't need to model deeper into the state graph.
That would have been a good article. The saga pattern could have just been a footnote to it.
Instead of untangling the mess, just cut the gordian knot and throw a nice error of what failed and what was aborted.
So instead of having a complex logic. Have a simple lambda function that talks to a queue. That's it. It accepts an undo command. You read a command you stuff it in the queue done. No DB, No servers. If you were running this yourself. You will have a simple API (distributed) that does the same to a distributed queue/cache. Done.
Your complex job can now pick up the undo commands from the queue and execute with logic to retry if for some reason it fails.