But those were actual problems back then, and they were solved only through significant engineering work to hide them, each of which had their own problems.
Frameworks like .Net WebForms were created to abstract and hide a lot of this from developers, with things like long encoded strings of "view state" that would be re-posted on each request, by serializing things to the URL, or by saving them to Cookie-backed sessions.
But each of these has issues, from privacy concerns using the URL, to security concerns with the "view state", to concurrency and integrity concerns with sessions.
IMO, the biggest reasons these didn't stand out as huge problems in the early 2000's was because:
(a) we didn't use the web like we do today, and our expectations were very different in how things would work if we, for example, added an item to a shopping cart
(b) most heavily interactive / app-like things that more closely work "the way we expect" today, were either still done as desktop apps (like business software) or were implemented as Java applets, Flash, or something else of the sort
(c) in the rare cases that neither (a) nor (b) applied, it was because some very good engineers put in a lot of work to make it work that way.