"User-space data may not be resident in RAM"

If you apply the rule of thumb that swap space should equal twice the physical RAM(*), then you only need triple the amount of RAM to eliminate swap altogether. That could happen in a year or two depending on how well Moore's Law applies to RAM production. Of course, software becomes more bloated at the same time, which is why we still have swap space, but I think the improvement in machine size is slowly outstripping the rate at which programmers can add bloat.

As far as I know, Android systems don't have swap space. I would expect most embedded Linux systems to do without it also. A spinning disk is too slow, and swapping to flash memory wears it out. Meanwhile supercomputers will normally run a specialized application designed to fit into physical RAM. It's the medium-sized systems that still use swap, as a kind of last resort before breaking out the OOM killer. I think this middle space is likely to shrink in the years to come.

I take your point that programs may allocate a huge address space and then use little of it. That's a slightly different issue from swap: no 64-bit system has a swap file big enough for the whole virtual address space that some process might make, and you can have huge (but mostly empty) address spaces with no swap at all. But it would invalidate the property that access to user memory can never block. If the page had been allocated but not touched, a page fault would still be needed on first use.

(*) I know this rule came from various old systems and Unix variants in simpler times. I use it as a rough example of a fairly generous allocation of swap space, not that I am advocating it on current systems. My point is that even if swap is much bigger than RAM, that's still less than an order of magnitude to overcome.