I feel you've badly oversimplified about userspace. The fact is that what we really ran out of wasn't RAM but address space. And we ran out of address space years ago.
The address space consumed by applications includes allocated RAM, file backed memory maps, device backed mappings (e.g. from graphics cards for visualisation tools) as well as all the code and data associated with any libraries linked in, and any libraries those libraries link in and so on.
When the absolute hard limit of address space is 4GB (2GB on Windows and many other operating systems) it's very easy to reach this limit without needing 4GB of DIMMs, let alone 8GB. That was the point when 64-bit userspace development should have taken off.
But when it became apparent that nobody except Intel was interested in cheap low-to-mid range hardware, and that Intel had no clue how to build a 64-bit CPU, a lot of us were forced to hack around these problems, to write programs that would use huge complicated wrappers around pread() and pwrite() rather than just memory map a random access file, to allocate and de-allocate buffers only when needed for fear that we might ask for too much RAM at once if we used a faster algorithm that avoided thrashing the allocator, and so on.
And the result was software which sucks disproportionately to today's hardware capabilities. Nobody should be encouraging the development of more software like that now that AMD have shown Intel that they could just glue wider registers to their existing design and have a 64-bit CPU that performed well and was affordable (Yes, I understand this is a gross over-simplification).
Arguments based on SPEC numbers are a good antidote to the "64-bit will make everything twice as fast" weenies, but in practical everyday terms they don't mean a lot in most applications. They deliberately don't let you go through the code and say "Well, this approach is hopeless with wider pointers, let's do something different here instead". If my application runs 40% slower in 64-bit mode I'm going to go find the problem (I declared that huge array as 'long' integer? Whoops, that was stupid) and fix it.
My day job is developing and maintaining a 64-bit program, admittedly ours is a lot bigger than most, but we've been doing this for years, and its been reinforced over time that refusing to compromise for 32-bit was the right decision. The effect trickles down, and with new _laptops_ having 4GB of RAM these days it's crazy to be writing libraries (which is what the Flash player mostly is) that are explicitly written to be trapped in that 4GB address space.