(back to the topic)
Like the state-machines: the flow of actions can get from non-obvious to really confusing with if/then/else or switch/case implementations. Not separating the code under a case out into a function worsen the issue and may yield switch statements of several 100 lines.
I would not consider it bloat to have a mechanism/library/language feature to make that sort of code more readable even if it is not more performant (assuming no requirements exist that inhibit this choice).
Excellent example.
Someone creates a state machine which is too big and unmanageable. I don't think the effect may be measured by the number of lines - few hundred lines is not that bad, depending on the way it is all organized, even few thousand may net be bad. On the other hand, 50 lines may be enough to create a mess. The case statement for a state machine is reminiscent of the Spaghetti code of old ages, and if you don't think well, your state machine can turn into a mess very quickly. Assume this happens - you created a state machine which is unmanageable (happened to me few times). This is already a bloat. The solution to this is to simplify the design - may be use different set of states, may be use hierarchy, may be avoid the state machine at all, may be re-think your data structure. At any rate, you need to throw away the mess, re-think it and re-do it in simpler, more efficient and more manageable way. This is a sad situation, but you should've thought of this before.
What people do instead? They try to preserve the mess while changing the form - using libraries, creating tables, may be using function pointers, may be switching to C++. These things may be useful, but it is possible to create/maintain a mess with any of these. Somehow, changing the algorithms and logical structure of "already working" solution looks like impossible task. On the other hand, using a library (or similar) which may magically organize the messy project looks easy. They try to preserve the worthless existing codebase as if it was their flash and blood. So, libraries get added, languages switched. This adds more bloat, but doesn't really clean the mess - may be ever so slightly.
We all know where it all moves - more libraries, RTOS, bigger MCU, FPGA - things keep snowballing - there's actually no end. And what is it all for? To perform a task which can be done on tiny little MCU with much simpler code and much less of development time? If you ask, they'll tell you that all this bloat simplifies (sic!) their work and make time-to-the-market way shorter and the extra-cost of the hardware doesn't matter. What else you expect them to say?