Two separate issues.
That the vulnerability dates back to 486s, and shows up in dozens of unrelated architectures, speaks more to a fundamental quirk of the design concepts, methods and processes in cache systems.
It certainly wasn't a problem back in the 90s. The exfiltration rate might've been bits/second. No need for such tiresome methods when Java was alive and well, just as vulnerable and naive as everything else, back then.
Has the problem just gone unrecognized all this time? Was it recognized, but ignored -- rightly, at the time, for being too obscure and useless? Has it not been reconsidered since then? Entirely plausible.
Presumably, the same phenomenon can be found in many cache systems, of any type. How about timing access to web pages on a server (which are cached), to determine the traffic pattern of the site? (It would have to be done slowly, because the statistics of network latency introduces a lot of error that masks the underlying signal.)
As for updatable microcode, that's been tried from time to time, AFAIK. I suppose the vulnerabilities are (should be) the same as any software update mechanism: are the update instructions locked to the supervisor, or better yet, hypervisor? Are the drivers signed? Are the keys long enough, encrypted with generally-considered-secure crypto? (And, mind all the turtles beneath this. Like Intel's notorious problems with securing said hypervisor.)
Tim