What's going on here is that these speculative execution attacks are a new generalization of timing attacks, which have been known for decades. The fact that code which wasn't executed can influence observable timing artifacts is crazy, but like all things crazy, once you get over the crazy it's just a new tool in the toolbox.

Google has already come up with a completely insane way of generating computed branches that will try to keep the CPU from speculating around it, which is itself sufficiently crazy that there's already a StackOverflow page that tries to explain it.

My gut reaction is that software patches for hardware problems are stopgap measures. This reminds me of an ancient MIPS bug where a branch delay slot, if it was on a different memory page that took a page fault, wouldn't actually get executed. The workaround was to hack the compiler not to split branch instructions and their delay slots across page boundaries, while the proper answer was to fix the damn hardware.

The problem here, unlike the aforementioned MIPS bug, is that there's a clear definition of what it means to fix the MIPS bug. Here's an input that causes non-compliant output. Fix it. With these speculative execution attacks, the only definition that really holds up is something called "non-interference", which is to say that nothing that happens "over there" can have any observable impact "over here" (for suitable definitions of "there" and "here"). When you want to encompass timing issues, in a world where CPUs play all kinds of optimization games that have side-effects in the cache, the TLB, the branch predictor, and so forth, you've got no hope of having real non-interference.

I've seen several security people using phrases like "this will be with us for another decade", and I don't doubt it.