if/else if/else... can work if you are clean about it. The if/else can easily get complicated and unreadable if folks start coding combinations of flag variables and logical tests. And a misplaced "else" or set of "{}" can also make logic errors undetectable. In more complicated systems, the switch-case can often be clearer because it enforces distilling down the set of conditions into one state variable and the organization of (mostly) mutually exclusive blocks of code.
I suggested a couple more "else if"s because it fits in with what you already have.
There's a more general state machine design where leaving a state triggers its "exit" action, transitioning to another state (or back to the same state) triggers the transition action, and entering a state triggers its "entry" action; also an event can trigger an action while remaining in a state. Any or all of those actions can be a no-op if they're not needed.
I imagine most applications need only some of those actions.
you're suggesting that the "exit" action is the same for each transition, where as each transition is unique and can effectively combine an "exit" and "enter" action if needed
Sometimes it's useful to have an "exit" action for a state that's the same regardless of which transition is taken. In that case it makes sense to separate the "exit" action from each of the transitions' actions so as not to duplicate the "exit" action in all transitions.