Sometimes the super loop can be less -- super.
I certainly don't disagree! My point was more about what all that code translates not, not necessarily what the text file looks like. My main loops almost always to be Init phase followed by a very high level system state machine. Something you can generally follow with minimal scrolling, etc. There is not really behavioral code, other than that main switch for a state machine and function calls with descriptive names to understand what processes are in what state. If the machine grows bigger than a handful of "system" states then it needs to be re-thought.
I.E. something that you could start at main() and get a gross level understanding of where to go next. Something that you can easily see what processes are running in what state, etc.
Here is what I have generally observed.
1.) There are "software" people who obsess over what the text file(s) looks like for state machine encoding. These are the "Java people" of the world (not using this as a pejorative) who obsess over how a code looks more than it acts, use delegates and function pointers everywhere to make the text representation compact, etc.
2.) Then there are hardware people who have built state machines from raw gates or used a ROM as a state decoder. Anyone who does this or has written HDL look at the state machine design in C in a completely different way. Hardware is a lot less forgiving and doesn't give a shit about cute software paradigms. These people almost always use a switch as that IS the optimal way that a synthesize wants to see it in HDL. It is exactly how it would map to a hand wired ROM. Hardware can't crash, get funky, etc. as fixing silicon and cutting PCB traces is a lot more tough than fixing high level software.
Not to say there aren't people in the middle but those are the two bins that cover the 6-sigma in my observations/ I have always been more aligned with camp #2 but there are many CS people who do #1 as that is what they know. Neither is "right" or "wrong", it is just 2 different approaches.
Most of what I do has to fall into the category of safety certifiable and high reliability. That eliminatws 99% of the CS "fluff" from implementations. That stuff is nice in a classroom but useless when it comes to applications that simply cannot fail.
Not all behavior falls into textbook FSM implementations. That and if your system grows to a point where it takes 6-months to upgrade, there is something else wrong in the general approach. The problem needs to be rethought. This is not a problem with the choice of state machine implementation but the general solution to how the problem is solved.