I was asked to read Harel's paper as part of my thesis, I personally think this stuff is wonderful and foundational to computer science and computer engineering, researching issues like concurrency and system complexity. But I can see how industry programmers would find little direct use for it.
And yet the motivation for Harel's paper was his being approached by his nation's avionics industry to develop some concrete tech to help the EE and software engineers work with confidence in their development of reactive systems, ones with lives on the line.
One of the most interesting aspects of this story is the fact that the work was not done in an academic tower, inventing something and trying to push it down the throats of real-world engineers. It was done by going into the lion's den, working with the people in industry. This is something I would not hesitate to recommend to young researchers; in order to affect the real world, one must go there and roll up one’s sleeves. One secret is to try to get a handle on the thought processes of the engineers doing the real work and who will ultimately use these ideas and tools. In my case, they were the avionics engineers, and when I do biological modeling, they are biologists. If what you come up with does not jibe with how they think, they will not use it. It’s that simple.
Yes, being practically-minded (engineering-centric) was an important aspect and intention of the StateCharts formalism. But the disconnect today I think is because demographically on hackernews aren't avionics engineers or biologists, they're more like FAANG / SV developers and as many have said here they just don't see the relevance (and call them architecture astronauts or whatever). An aerospace specialist would expend the effort to learn a theoretical formalism, but an iPhone developer, maybe not so much.
And yet many the web or iPhone dev will wildly smear ad hoc state machines within modules and across modules in their codebase via if/case, maybe dressing it up a bit with redux, et al.
As the codebase grows, teams of those devs will labor under the constant threat of suffocation from the thrashing-swirling spaghetti of events and side-effects they themselves authored and don't know how to tame.
