Example #2 suggests that the underlying issue is the function having too many responsibilities. I can't disagree, but the solution conveniently glosses over the fact that the 3 new functions still need to be called from another function, and that function needs a name too!

This can be a useful tension in my experience, since it can indicate when there are too many layers between a program's entry point/composition root and its functionality.

For example, if the three operations in the example are the program's only responsibility, I think the proposed solution makes a lot of sense. But if this is only one step in a program, and especially if that step happens multiple times, having the operations wrapped up in a single function might start to make sense again. I don't quite agree that it's inherently bad code; at some level of abstraction, starting a new worker on a machine starts to look like a single responsibility.