In my experience the biggest problem is something that cannot be solved by the kernel anyway, which is the microcode updates. AFAIK it's impossible to get that performance back by any means, even the mitigations=off flag cannot do that.
Maybe look at QubesOS (it runs many desktop processes in separate virtual machines) which will give you defence in depth, and mitigates many other browser attacks as well as architectural ones. You could run your trusted stuff outside Qubes (in the dom0) where it I guess ought to run at full speed.
BTW I solve this problem by having a separate development machine for compiling and testing my own code which never runs anything untrusted. And that other machine is an AMD Zen 2 so it's not quite so vulnerable and also much faster for the price!
It is my understanding that these microcode updates get applied either by the operating system at boot time (applying the update every time you boot), or by the motherboard, if the BIOS was updated. As only this last method is "permanent" (or at least it requires you to downgrade your BIOS, something not always feasible) if you never upgraded your BIOS, I guess it should be possible to prevent the OS from applying the updates.
It's usually upgraded by a BIOS update or by Windows update. Windows update send driver/firmware updates, security patches or general updates if the vendor wants to support that way of distribution.
I think it's quite device specific and method specific whether the microcode can be upgraded and downgraded the same way.
If I can’t do that and I have to choose between fast/insecure or slow/secure I’ll take my chances with fast/insecure. I’ll rather give up doing anything sensitive on my machine than give up 5% perf.
Or can a properly designed attack break out of the VM and hardened kernel?