Now, think about 2015, or 2020. If hardware continues to improve and software design doesn't introduce something new that absolutely kills build time, it might be possible to build a complete system in an hour or less. Or, given the massively parallel processors that are slated to become commodities this decade, the limiting factor of a compile may become the storage backend, not the CPU.
So if you have a hypothetical 2015-model SATA 3 SSD at 6 Gbps, and it can nearly max out the SATA pipeline, and a 16 core CPU with hyperthreading, it may be possible to build your entire system from source code in the same time it takes to install the binary packages of Ubuntu today -- about 15 to 60 minutes. At this speed, you probably don't want to have the build printing to a console, because the terminal will actually slow down the compile as it waits for the graphics driver to render the text. With your nice 24GB RAM system, though, you can probably just offload the compile log into a RAM buffer, making it available to the user if it fails.
Of course, under these conditions, it would be even faster to install the binary packages -- but is it really necessary to knock installation times down into the 90 second range? I think most users would be perfectly fine with a 45 minute install time.
What Gentoo needs to focus on, if it wants to remain relevant, is ease of use. It needs a nice graphical installation wizard that asks the user questions, and based on those questions, makes the appropriate optimizations. This might help extend the time that the project remains significant, because it will bring Gentoo in line with Ubuntu as far as eschewing arcane console commands. Coupled with a solid desktop experience with GNOME or KDE, it could be made very nice indeed.
For example, one of the first questions could be, do you intend to run this installation on this computer only, or potentially on other systems? For a static desktop install, you answer the former; for an OS on a thumb drive, you answer the latter (you might take it to your mom's house where she doesn't have a processor supporting XYZ feature that gcc has compiled everything with). Then it can ask you, for example: Do you have a printer? Yes / No / Might at some point. Currently, most distros assume "Might at some point" or "Yes", but with this choice, you still have the option to answer "No" and completely strip out anything print-related (CUPS, gnome printing facilities, etc). Then it can ask you what sort of graphics drivers you want, which filesystem (and explain in one sentence the difference between them), etc.
Such a configuration wizard would be too detailed for your typical Windows user, who just wants things to work; for them, Ubuntu (which doesn't ask questions) or Windows / Mac (which really doesn't ask questions) would be best. But the wizard would lower the barrier of entry, while still providing the space and RAM savings that you value so highly.
The unfortunate part is that, by the time we have systems that can compile Gentoo that quickly, the space savings, performance, and RAM savings will be so utterly insignificant that you may as well ignore them. It will be as insignificant as Calculate performing some 200-second test 0.01 seconds faster than Ubuntu.
If you were to construct a graph of history, starting at the foundation of the Gentoo project and extending to 2020, you would be able to show full system compile time steadily decreasing, while the relative performance benefit of that compile time would also be steadily decreasing. Therefore, I am still not convinced that Gentoo (or generally speaking, source-based distros) will remain relevant asymptotically, even if it becomes easy enough for a graphically-oriented power user to install. Even if we assume that compilation time of the entire system is negligible -- as in, less than a second -- it still takes the user more time to install the system because they have to make all those choices. In the far-flung future, 99% of choices have zero impact on the performance of the system, because the resources available are so robust. The 1% of choices that have a measurable performance impact (modern example: compositing or not) are configured at runtime, both for source distros and binary ones.