Actually I think in most cases the simplest and most efficient architecture is when your server
creates a process for each specific type of thing it needs to do and then simply delegates incoming requests. http://www.okws.org/doku.php?id=okws is a good example.
Ah, but now it's a lot harder to share anything that isn't simply coming out of a shared library; pre-cached computations, any code that isn't in a shared library (like Perl or other interpreted code), any expensive computation that must be done per-process, etc. Forking off children is virtually impossible to beat on the efficiency front; people tend to grossly overestimate the expense of a "fork".
The only way to win with the approach you suggest is if you have some sort of massively complicated server that you only ever need some small part of at any given point in time, allowing you to do a lot of swapping in and out of memory. I've never seen such a beast and can't really come up with a non-contrived use case. YMMV, but it certainly isn't a common case.
(Yes, Perl isn't exactly interpreted, but from this point of view it certainly isn't a shared binary library.)
Although I believe you're wrong about the actual utility of this kind of data sharing across processes (and also making exaggerating claims about complexity), I might change my mind if you provided a specific real-world reference example.
Actually I think in most cases the simplest and most efficient architecture is when your server creates a process for each specific type of thing it needs to do and then simply delegates incoming requests. http://www.okws.org/doku.php?id=okws is a good example.