If we say a typical Rails process is 150MB, then consider several hundred of them...
150MB * 300 = 43GB
So, while your point is valid, in that there is value in safety and code simplicity, we're not talking just "a little" memory. Consider your use case, that's all.
Nevertheless, the memory requirements of a multiprocess server are not a linear function of the footprint of the master process. fork(2) on modern Unices (including Linux, since, like forever) has copy-on-write semantics for a child's memory usage. So when you fork a new process, the memory overhead is relatively small (only the page tables are copied, not the heap, and never the program text or shared libraries).
Only when a child process modifies or allocates a new heap page or exec()s another program will it incur additional memory overhead. So the additional memory required by a child Unicorn process (assuming the parent preloads the application server code) won't usually be anywhere near 150MB (and if there's a memory leak it's trivial to free it up by killing the child after it services a request).
There has been plenty of ink spilled on the subject, but here's a good read: http://msdn.microsoft.com/en-us/magazine/cc163744.aspx
I tend to think out of the box for multiprocess shared memory - Kyoto Cabinet and Redis can be helpful here, to name a few. Even SysV shared memory is pretty easy to use.