(2) is explicit - you draw lines (curvy arrows) to show transitions
(3) is implicit - you have to read the code to see who-depends-on-what.
Remove (3) and you have a wonderful notation that I call HSM's (Hierarchical State Machines).
Move (3) into its own notation and you get "network diagrams" (aka "box and arrow diagrams"), and the FBP-like stuff that I build (currently called "Arrowgrams", formerly known as "bmfbp" (for Bare Metal FBP)).
(2) and (3) are, both, simple notations.
When you try to combine the two notations, you get accidental complexity.
Harel wrote a follow-on paper about the micro-semantics of his notation and told us that everything must work in a lock-step manner.
Arrowgrams gives you concurrency in a simple form ("multitasking is easy" :-)).
HSMs give you anti-state-explosion.
I built a full Harel Statechart textual language (some 8 passes, iirc), then backed off and simplified ((2) hierarchical state machines and (3) a message-passing kernel).[1]
If you think in terms of communicating-state-machines, you brush up against Actors-like thinking.
[further: YACC dealt with the "state explosion" problem, too, but, over-specified (IMO) and didn't allow users to control the explosion handling in an explicit manner]
[1] The kernel is simple. The current implementation is in JavaScript (this is a way to show just how simple this can be - if you can do it in JS, you can do it in any language :-). I, also, have done it in HTML+JS). See, also https://guitarvydas.github.io/2020/12/10/5-Whys-of-Software-Components.html and https://guitarvydas.github.io/2021/01/16/HTML-Components-Arrowgrams.html.