The significance of this is Elon Musk, who is the self-driving Uber of dot.com billionaires and is the hero of our times.
Well, I knew Steve Jobs well enough, and have met a few civilian astronauts and a bunch of other rich people. None of the others seem to have done so much for the long-term future of the human race as Musk has in leading the path to more affordable spaceflight.
Well, it beats making them into the world's most complicated airplanes as with the space shuttle. SpaceX has proven that they can do vertical landings of the first stage intact onto both land and a seagoing barge; after a trip out of the atmosphere and to about 1/5 of orbital velocity but not into orbit. They plan to do a parachute-less vertical landing of the Dragon capsule after a heat-shield re-entry. That turns out to be far less expensive and complicated than a space plane. It does turn out we need a lifting body for much larger vehicles. It still doesn't have to be a plane, though.
We don't need wings.
If they are going for the Darwin award does it matter either way?
Scary part is the fiber that would have been put in in the 70's would work today. It's proven over a long time to be adaptable.
On a 8-core machine, a processor will be placed into a wait queue roughly 7 out of 8 times that it needs access.
You just snuck into your analysis the assumption that every core is memory saturated, and I don't think that all the memory path aggregates in many designs until the L3 cache (usually L1 not shared, L2 perhaps shared a bit). The real bottleneck ends up being the cache coherency protocol, and cache snoop events, handled on a separate bus, which might even have concurrent request channels.
I think in Intel's Xeon E5 line-up there are single-ring and bridged double-ring SKUs for forwarding dirty cache lines from one cache to another (and perhaps all memory requests). This resource can also drown for many workloads.
In many systems, you have all these cores running tasks which are fairly well isolated (not much cache conflict), except they all want to be able to allocate as much memory as they need from a giant memory space (e.g. a TB of DRAM) so they fundamentally have to fall through to a shared memory allocation framework.
You can learn a lot about the challenges involved by following the winding path of something like jemalloc as increasing concurrency levels expose yet another degeneracy.
The real problem with this field is that there isn't a single, simple story like the one you tried to tell. There are usually dozens of ways to skin the cat, each with completely different scaling stories, with different sets of engineers who are good as tweaking or debugging those stories.
At this point, what you have is a fragile coordination problem between your solution space, your architecture, and the engineers you employ, forcing ambitious ventures to crack out the golden recipe: pour in seven cement mixers full of head hunters, one 55-gallon oil drum of exclamation marks, a metric butter tonne of job perks, and agitate appropriately.
It's eco smugness and should be a cause for death.
Any given program will expand to fill available memory.