There's nothing stopping you from tracking client state in a a simple window.state object. This object can be of arbitrary composition, so I see no reason you cannot manage even the most complex UI state in this manner.
For me, minimal web development means doing as much as I can at the server. This includes tracking client UI state if feasible. The more stuff you have in 1 domain like that the easier it becomes to control complexity.
When your state machine is split between 2 realms is when you get into traps that things like React were created to resolve.
I agree that if you have state in two places you're doing it wrong. That's why I keep all my state client-side (the only thing in session storage is your user ID if logged in). My server is basically just a thin wrapper around my database, providing an API for my client to call.
For me, minimal web development means doing as much as I can at the server. This includes tracking client UI state if feasible. The more stuff you have in 1 domain like that the easier it becomes to control complexity.
When your state machine is split between 2 realms is when you get into traps that things like React were created to resolve.