A multiprocess server isn't so much about performance, it's about reliability and some better predictability (not perfect if you aren't throwing away all state, but at least better). And in part about architecture. Putting stuff into a session isn't particularly worse than putting stuff into a global variable. Better, really; at least you are being explicit about the storage you are doing. I already abhor losing any information on server restart -- I always regret it later -- so I don't put anything valuable in memory. If it's too hard to do otherwise, then that is something to be fixed, it's not that we should use the poor man's persistence of threading and global state.
"I already abhor losing any information on server restart -- I always regret it later -- so I don't put anything valuable in memory."
For my applications, there always seems to be all kinds of temporary crap that I'd like in memory to avoid recomputing, but that I can always auto-re-derive from my normalized data on a restart. I guess either we're writing different kinds of apps, or we're not really disagreeing, or a little of both -- what I keep in memory isn't "valuable," either, but I do enough of it that if the only caching API I had were a session-based one, my code would suck.
(This isn't really about premature optimization, either; I could point at any number of pages where doing a dozen queries to set things up once a day or once a server restart is okay, but doing it once per page load is unacceptable with any number of users.)