Thank you @ariana for bringing this topic up and also for the link to David Khourshids video. I've actually designed state machines for UI state when I was asked by designers which edge cases a UI they've designed could have. So, after doing this a few times (with huge success), the natural question I had was if this is maybe something developers do in common in larger companies.
One thing I've learned from the talk is Hierarchical Finite State Machines (HFSM), which was one of the issues I've come across when trying to build larger functionality into non-hierarchical state machines, which lead to the State Explosion already mentioned by David. They seem to solve my issues there. 
And I also totally agree that designing the state in TCA using HFSMs makes a lot of sense and goes in line with the composability of TCA, where each "box" / hierarchy in the state machine can be represented as a separate set of store + reducer combination.
The big question for me is though: How exactly could we make use of HFSMs in TCA?
Here's some more specific questions that come to my mind right away:
Should there be a tool that can read Swift code and generate state machines for visual analysis?
Or should it be the other way around and a visual state machine get converted into Swift code with stubs? I guess both directions together would make most sense as this makes it possible to keep the two in sync with each other at all times. Also, at which place exactly should this be implemented, right within TCA or as a community extension kind of library? Is there a standard format for HFSMs to store them in? Are there already (open source) tools for creating HFSMs visually that we can make use of?
So, you see that I'm quite interested in this topic but also have a lot of questions. I'd love to (help) building tools around this idea and exploring how we can further simplify the process of reasoning about different states in our applications.