I wouldn't even bother mentioning X86(64) in the context of RISC-V. When RISC-V becomes financially viable for manufacturers they'll switch. Cost alone is enough to justify the change. Most of the innovation happening these days is in the mobile sector with mobile devices replacing more and more of the average consumer's computing needs. This alone has made for some pretty nimble software already. Every device sold with one of those ARM-based processors has an Arm holding "tax." ALL vendors are happy to not pay that tax and will be even happier to have nothing to do with ARM Holdings at all (I've heard they're shit to work with). Arm and RISC-V are both RISC architecture; not hard for software to switch. What happens in the mobile sector will trickle down to the rest of the tech industry. Microsoft has even embraced RISC with Windows on snapdragon devices. I doubt the consumer will even notice a difference.
Doesn't have to be native, only fast enough to power gaming, office and extensive image collections. Only one of those requires lots of computing horse and that mainly on the GPU (though there are some offenders like PUBG or Minecraft, the later also slurping up a significant chunk of memory bandwidth)
I think you are confusing EFI firmware with CPU microcode, the EFI does often contain microcode ROMs to upload to the CPU at boot but the microcode itself is proprietary and signed and reverse engineering is quite a challenge - In fact there was a submission of a presentation here not long ago showing the painstaking progress of a small group of individuals attempting to reverse engineer some intel microcode.
I assure you there is no working libre microcode for intel CPUs and it seems far more likely people will successfully focus their efforts on open source hardware before being able to successfully replace substantial microcode of complex closed source hardware.
In "libre" EFI mods they tend to disable ME as well, maybe you were confusing that with microcode?
One of its omissions is that it excludes microcode ROM updates that can be inserted at power on by the BIOS
As I understand it. The CPU's of that era are old enough that they can run without updated microcode being inserted either at system bootup or operating system boot time
Ommiting microcode from the EFI has nothing to do with whether a CPU has loadable microcode capability or whether it is vulnerable. Unless you are using some pre-pentium intel CPU, an initial microcode revision is included in an on die ROM and an updated revision can be loaded at boot. Loading it in EFI/BIOS vs OS is a matter of convenience, which is why it's usually left to the OS these days.
Not having microcode blobs in the EFI doesn't magically mean your CPU doesn't use microcode or doesn't need patched versions to stay secure as in this case.
I do find it a little deceptive with some of these "libre" projects where they draw an arbitrary box around something, evict all proprietary blobs from it and then announce victory despite it operating underneath a whole load of other blobs that could easily subvert it. However I suspect the intent behind evicting microcode from libreboot was more due to it being a redundant task for EFI today.