got on my reading list by virtue of the misfortune of dealing with code written by programmers who adopted the book's approach.
The thesis was that state machines are a powerful formalism that can be fully verified because all the states and edges between them are known. That's half-right: they are powerful because state transitions are essentially "goto" by another name. In practice goto-based programming is brittle to requirement change. The damning part is that state machines don't live in isolation: they interact asynchronously with other state machines and the world at large. The dynamic behavior of these interactions is probably important! and not part of individual state machines. You'd need to co-simulate them.
I feel state machines have their place where no higher-level construct (usually I prefer coroutines) fits the job and it can be kept small and rewritten on requirement change.
I had not learned about automata theory and electric engineering formal methods before, so I'm still trying to piece it together, seeing if I can fit this to my work and such, seemed very promising and kind of a "missing piece" in the puzzle to me. In that it seems to really allow to better model system behavior in a way that potentially could bind it to a spec, give new tools for seeing blindspots, etc, at the same being abstract enough that you could capture much with actions, control values, conditions and states.