There is absolutely no doubt in my mind that that right variant is significantly better. I prefer it because of the smaller lexical scopes, because it's easier to test and most importantly to me it's easier to extend and to understand what the workflow intends to do. If I had to maintain code like this, I imagine in my day to day, I'll likely only have to extend it by only touching the `addToppings` function, the rest can stay the same. If I have someone new joining my team I can easily guide them to this `addToppings` function and ask them to add support for pineapple and ham, nobody needs to be overwhelmed by the entire system and their task would be done in no time. I do acknowledge the question is about readability but I don't think it's possible to ignore testability, manageability and extensibility. I think the inlined approach simply does not strike a good balance of the aforementioned.
As someone who prefers the underlying of the non-linear right side example, it's written terribly code (which is puzzling since it was supposed to be the halo case)
The prepare function is the main issue: it creates the pizza and adds toppings. If the pizza had been constructed at the top of createPizza, then `addToppings` `bake` and `box` were called, it'd be strictly clearer than it is now.
Now obviously this is all from a contrived example, but I think the underlying lesson is: bad linear code is less tedious to deal with than bad non-linear code. With bad overly long linear code, at least the whole mess is in front of you. With bad non-linear code stuff is hiding stage-left, there's side effects that names are hiding, you're at the mercy of tooling for navigation, etc.
Maybe if you know what you're making is doomed to be bad code (think convoluted business logic driven by the real world), maybe prefer linear?
