Other resources folks might want to check out are:
+ David Harel's original paper on the statecharts formalism (which Sketch.systems implements): http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso...
+ Ian Horrock's "Constructing the User Interface with Statecharts" book: https://amzn.to/2sT1e4x
It's also worth noting that Sketch.systems doesn't do any kind of formal analysis or checking of invariants.
If you're interested in that sort of thing, look into TLA+ (video intro: https://lamport.azurewebsites.net/video/videos.html) or Alloy (http://alloytools.org/).
Here's the thing. As developers, we write implicit state machines in our UIs all the time, in the form of boolean flags, or enums if we're feeling disciplined, or peppered if-else statements everywhere. Arguably, most (if not all) UIs can be represented as explicitly classifiable states, and actions that can occur that can transition those states into other states.
So I'd argue that having _some_ sort of declarative formalism for describing your app's states and transitions is much more beneficial than having an ad-hoc way of imperatively changing states, which most of us developers are wont to do, since it's "easier" to implement.
Since statecharts are hierarchical graphs, there's also the possibility for automatically analyzing, optimizing, and generating full integration tests for user flows given a statechart spec.
I agree that trying to use statecharts everywhere is fitting a round peg into a square hole, but thinking about the UI in terms of states, and actions in terms of something that is simply emitted instead of something where application logic is stuffed into, will greatly improve how UIs are developed in the future.
Relevant must-read: https://www.amazon.com/Constructing-User-Interface-Statechar...
Get dozens of book recommendations delivered straight to your inbox every Thursday.