I've always been strongly in the stateful web app camp, and I don't find anything hacky about sticky sessions:) But I think the divide between the stateless and stateful camps may come down to a combination of initial technologies used, and web application complexity.
At some point, with a complex enough application, reconstituting all of the required session data and state for each request becomes a massive performance bottleneck, and stateful sessions solve that very nicely. Most app tiers support session failover pretty nicely, and many clients I've worked with have logic where if the session doesn't exist (i.e. if their session's sticky server has crashed or been removed) then reconstitute the state based on a cookie value. Either approach gives you the best of both worlds - the performance of stateful sticky sessions, and the cluster flexibility of stateless.
But with simpler applications, with less session data/state to manage then stateless is probably fine.
Sorry if I'm misunderstanding yours or GPs point but I think GP was recommending storing app session in some 3rd party cache outside your app server tier, not having nothing stored in session at all.
But reconstructing session from cookie value would work just as well I suppose, at the tradeoff of having everything you want stored in cookie (vs storing just session ID in cookie and having that ID mapped to data in one of the aforementioned caches or other alternative)?
At some point, with a complex enough application, reconstituting all of the required session data and state for each request becomes a massive performance bottleneck, and stateful sessions solve that very nicely. Most app tiers support session failover pretty nicely, and many clients I've worked with have logic where if the session doesn't exist (i.e. if their session's sticky server has crashed or been removed) then reconstitute the state based on a cookie value. Either approach gives you the best of both worlds - the performance of stateful sticky sessions, and the cluster flexibility of stateless.
But with simpler applications, with less session data/state to manage then stateless is probably fine.