There is definitely a learning curve to state machines, and even more so with statecharts/UML. It's much, _much_ easier to start coding an application from a bottom-up approach (start coding, colocate app logic wherever it's needed, refactor later) than a top-down approach (systematically plan the entire higher-level behavior of your app's various parts before writing a single line of code). That's why it's slow to catch on in the application development (web + native) part of the tech world.
However, in game development, hardware development, etc. state machines and statecharts are more commonly used. To me, the ability to declaratively structure your program's behavior as a directed graph opens the door to the possibility of being able to automate integrated tests (simple path/shortest path/etc. algorithms), statically analyze logic (are all states reachable? are all events handled?), optimize paths, add and remove features without worrying about if some other part of the application will be adversely affected, have smarter analytics, visualize app state, and much much more.
I know there's critics to FSMs where other more idiomatic language-oriented approaches would suffice (I myself absolutely detest the OOP state pattern - it's a needlessly imperative, hard-to-analyze state machine), but I think if developers further understood and saw benefits to functional, declarative, reactive programming and statecharts (a huge improvement over conventional FSMs), application development as a whole could reach a new level of efficiency and robustness.