1) Your user interface probably has more edge cases than you or your designer anticipated, and IME the most efficient, understandable way to deal with these is in as-simple-as-possible plain-old-code if/else business logic. The further away you keep code like that from anything "frameworky" the less likely you are to regret it as tech debt.
2) Many of your state transitions probably share similar helper logic. So you want to break that stuff out into its own non-state-based organization anyway to avoid copypasta, and at that point, similar to the above, representing different use cases as linear code as much as possible is a low-cognitive-overhead way to organize your biz logic. That is to say: I think your "states" should be big and chunky - occasionally one feature's flow will transition you into a different feature, but whenever I've tried to push that model down to the individual screens and buttons level, it's caused self-induced pain.
If I had to reduce it to a soundbite, I'd say: your business logic is likely to be inherently complex. Don't intermix that complexity with the technical complexity of your application framework if you can at all avoid it.
(Where this KISS approach goes wrong in practice is you don't have enough team discipline about organizing your biz logic code, or you try to share the wrong things/too early, and some biz logic ends up in every layer of the UI, and you get lots of big pull requests touching lots of files with hot spot files frequently having merge conflicts.)