There are cases where you need more than 4 GB of virtual address space even if you're not actively using 4 GB of physical memory.
Our application, for instance, uses mmap heavily and pretty easily tears through 4 GB of address space while comfortably running on a machine with less RAM.
One other nitpick I'd add there is that 64-bit runtimes consume drastically more memory -- mostly meaning interpreted languages, JVMs, etc. Compiled C, C++, etc. fare better since they usually make use of the stack more widely rather than having everything running through three levels of indirection (thus using lots of 8-byte pointers) up in the heap.
A 64-bit OS build consumes more memory, even if your app does not.
Perhaps there are special cases where it still makes sense, despite losing memory (though your example use case makes me feel funny, and not in a good way, but I don't know enough about such things to argue), but in the general web hosting case, it is stupid to have a 64 bit OS with less than 4GB of RAM. As you note, the difference is much more dramatic in dynamic languages (Ruby, Python, PHP, and Perl applications simply explode in size when run on 64 bit systems...like 50%-75% larger).
> though your example use case makes me feel funny, and not in a good way
mmap is a way of treating files or parts of files as memory when interacting with them and is used pretty often in low-ish level stuff that does file wrangling as it's one of the more performant ways of doing random access on a file. Since those files are being accessed as memory they consume space from the 4 GB of address space on a 32-bit platform, but don't take up physical memory (except insofar as their contents is cached in disk buffers).
That's one thing that's often misunderstood with the 32-bit limitation -- address space is limited; modern "32-bit" CPUs have used 36-bit addressing internally for quite some time, meaning they can address 64 GB rather than 4 GB of RAM (http://en.wikipedia.org/wiki/Physical_Address_Extension).
Because of the address space limitations you also don't have a full 4 GB to work with inside of a process on 32-bit platforms -- if you try to allocate a 3.5 GB block of memory it will usually fail because there's no contiguous block of address space available, even if there's 3.5 GB of unused memory. Typically the Linux kernel reserves 1 GB of address space for itself, and user space reserves a block for memory mapped I/O devices as well.
There's a pretty good article explaining some of this here:
Now, all of that said, I'm not disagreeing with your advice -- just noting that there are some (mostly corner-) cases where you do need the address space, but may not need the physical memory.
Our application, for instance, uses mmap heavily and pretty easily tears through 4 GB of address space while comfortably running on a machine with less RAM.
One other nitpick I'd add there is that 64-bit runtimes consume drastically more memory -- mostly meaning interpreted languages, JVMs, etc. Compiled C, C++, etc. fare better since they usually make use of the stack more widely rather than having everything running through three levels of indirection (thus using lots of 8-byte pointers) up in the heap.