To fully describe client side state you also need to look at DOM and cookies. The server can effectively see this stuff too (e.g., during form post).

I design my SSR apps so that as much state as possible lives in the server. I find the session cookie to be far more critical than the URL. I could build most of my apps to be URL agnostic if I really wanted to. The current state of the client (as the server sees it) can determine its logical location in the space of resources. The URL can be more of an optional thing for when we do need to pin down a specific resource for future reference.

Another advantage of not urlizing everything is that you can implement very complex features without a torturous taxonomy. "/workflow/18" is about as detailed as I'd like to get in the URL scheme of a complex back office banking product.

This entire article is an argument against your approach here, and you're not really addressing any of its points.

Basically, your approach is easier to code, and worse to use. Bookmarks, multiple tabs, the back button, sharing URLs with others, it all becomes harder for users to do with your design. I mean feel free, because with many tech stacks it is indeed easier, but don't pretend it's not a tradeoff. It's easier and worse.

Maybe I'm misunderstanding what you're saying but applications like this tend to be horrible to use. How do you handle somebody navigating in two tabs at once? What about the back button?