Since this vulnerability class was previously unknown, hardware didn't have much protection against it, except by accident (or as a side effect of more conservative design). Being in hardware, they are difficult or impossible to workaround in software. And they were found in common hardware most people have. This all lead to them being widely reported by the tech press.
Spectre was more impressive than a new idea: it was a brilliant execution of an idea that every architect eventually had. Rowhammer was similar. Everyone knew that it was possible to get boned by physics, but it can happen at an arbitrary place in an arbitrary way that isn't captured by any model. Rowhammer wasn't impressive because it was an idea, but because it was a simple, obvious in retrospect, way to exploit physics to bypass the models.
I remember reading papers in the mid to later 90s on just this topic, in regard to processing on top secret systems.
Most of the infeasiblility at the time was of running code on remote systems at the same time. Things like javascript were not everywhere at the time and most computers only had one core.
Compare and contrast their handling of the stream of vulnerabilities in the past few years to the FDIV bug in the 90's. The FDIV bug was the first time I remember a hardware bug making national news. Intel just about shit themselves over this apologizing profusely, offering free processor swaps, billion dollar write down, talking about how this would never happen again etc. A big part of the reason they took it so seriously was that there were still a number of other alternative CPU manufacturers trying to compete with Intel at the time and it was far from certain that x86 would become the undisputed ISA for PCs. (this was pre-Windows 95) All this, and the vast majority of people would never ever experience the FDIV bug even if their processor had it.
Times change, but the lesson remains the same: competition is good.
On the other hand, interest in this topic among the public has definitely grown since branding departments started getting their hands on the exploits and Bloomberg published that sensationalist Micro story so it's a self reinforcing cycle.
Considering it was published with the intent to "move markets" I would consider it a fraudulent Micro story.
Several years ago it felt like we barely went a week between Flash vulnerabilities.
Then someone found a major vulnerability in the JVM, and that became the centre of attention, and it felt like we were having to patch the JVM every single month.
Then something else came along and all eyes got focussed on that... rinse, repeat.
Right now the CPU is becoming a focus. We've probably got another couple of years of this before it'll settle down.
CPU is interesting because it's a lot harder to exploit, it's much less by way of finding low hanging fruit, unlike Flash and JVM.
And now that code can adversarial effect you?
That's why it became such a hot topic.
These secure enclaves are routinely used for extremely sensitive data, surely it's more worth stealing than someone's WiFi credentials.
Edit: So yeah, I'm not sure it's worth all of the complexity of an SGX attack. There are probably easier ways to get the credit cards.
E.g. you might want your credit card processing in an enclave even if it's your own card, simply to hide it from any rootkits or malware you may have installed.
An attacker doesn't want to remotely steal your iPhone or laptop. At most they want to unlock it after they steal the physical device.
Injecting a bios worm into a data center is more of a concern.
I've never used a web store checkout system that wasn't based on browser forms, or any mechanism that felt like asking a secure enclave to sign a transaction. Google Chrome offers to store your credit card numbers for you, but that's just so it can autofill web forms.
Apple Pay or whatever, sure, on their hardware. Macbooks, I'd think it uses the touchbar secure enclave. But nothing really uses SGX on Intel except Netflix DRM.
CPU designers have made complex architectural decisions to speed up execution. In the case of spectre, it's to speed up single-threaded execution. In the case of this, it's to optimize security features. An analogous case is AES256, which was chosen because it's fast. But it's fast because the s-boxes use the private key as an index into an array, so there's caching. But this introduces a side-channel, because based on time to execute you can infer the private key.
That’s not to say systems were all insecure in the past. You just didn’t trust computers to be secure.