Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?
Context switching was in the Apollo 11 guidance computer https://www.youtube.com/watch?v=xx7Lfh5SKUQ
The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on.
Keeping the security context intact and separated is a gargantuan task.
To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.
You write data inside the registers, yes, other processes can read these registers.
It always been like this, and is absolutely normal.
It's the responsibility of the operating system to clear the registers if it is switching context.
These side channel attacks allow an attacker to read registers from other processes before any context switching has occurred, or independently of any context switching (even if the OS has been written to correctly clear state).
It's not the guaranteed security as much as the advertised speed that's the issue. If they put out a chip which could only be used at half the advertised speed or else it would catch on fire, nobody would argue that they should be let off the hook because they didn't guarantee that the chips were fireproof in their ads.
If the chips can't perform at advertised speeds safely during typical use they're not delivering what was advertised.
In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT.
Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists.
If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration.
You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.