Typical web sessions are usually handled by web developers on the servers themselves, meaning that most programmers will defer to the environment's available Session object for tracking their users. This also applies to trusted and untrusted sessions (difference being that a user authenticated himself to bind his session in some shape or form).
The cumbersome data part of the session is normally kept in server-landia, whereas a token of some form will usually be inserted in the user's cookies, so as to be able to synchronize the Client with the Server's session for that user. Some developers might supercharge their dependence on server sessions by generating a hefty dossier in his user's sessions. I would imagine that some SaaS or specific design web apps might do this. On the other end of the spectrum, where sessions were really implemented firstly, we'd have the typical e-commerce shopping cart, the Session containing the cart and its items, and the cookie a token that could be or not, associated with a full-member account somewhere on the server.
In the later cases the actual session storage is usually not very sizeable, a shopping cart's rendition usually requires a hefty number of database queries, product compiling, shipping & handling charges to calculate, credit card details (which for obvious reasons shouldn't even belong in a Session in the first place) and so, the Session becomes a rather flimsy User-tracker objet really.
Back in the days that there were no Server Session objects, we'd program our web environments using pure and simple parameter-passing. Granted it could turn very complicated, but the same logic applied as well, we could store a user's progress on some work in a database on our servers and just worry about passing a User-tracking token in our parameters, with the rest of the parameters usually applying to the current page's inner workings.
So what changed since the 90s concerning our handling of Sessions and User tracking tokens? Aside from many laws, on the server-side, nothing at all. Sessions are still handled like data-chunks that need to be implemented through a backend service, and usually, that service needs to be made redundant, fail-safe and fool-proof.
When server sessions became the talk of the bloc, technologies were evolving to permit horizontal scaling of web solutions. And the Session object went down the same road; ie; how to we make sessions horizontally scalable along with our web servers ? So, really, Server Session handling has always involved some extra work, and for some web entrepreneurs, that extra work could entail failures, problems and grave security situations.