(a trie ain't nothing but a degenerate state machine)
On second thought, this is a wonderful hypothesis, because it would explain so much about the modern software environment...
As you add more states, you do not need to edit the existing states - well only the bits where you need to transition to the new state. This makes it much easier to maintain and reason about.
Each subsystem can be its own state machine too.
Made a menu selection? State Machine.
Interacted with a dialogue box/an HTML form? State Machine.
Used a dropdown/popup suggestions list? State Machine.
Written async code? State Machine.
Used a VM? State Machine.
Used a compiled executable? State Machine.
https://lamport.azurewebsites.net/pubs/state-machine.pdf
"safety" (nothing bad ever happens) and "liveness" (something good eventually happens) are two key properties for systems, and they both have easy formalisations in state machine terms.
Here is a brief introduction which may be of help:
https://www.cs.princeton.edu/courses/archive/spr06/cos116/FS...
A "State Machine" is a mathematical abstraction (i.e. a "computation" model) for the workings of a concrete machine i.e. A real Computer running a Program. When you start to write your programs as state machines you make its operations explicit, unambiguous and clear thus greatly reducing errors and guaranteeing "correctness". This is what makes it "essential".
I highly recommend studying Michael Sipser's Introduction to the Theory of Computation to understand this and other computation models (any edition will do).