It's likely they could disable speculative execution in its entirety, either in ucode or UEFI, but that would harm many compute-intensive workloads by 5-10% or more, so my guess is that somebody decided to push this page table mitigation instead, taking the hit on the syscall/hypercall side as that's perceived as "less bad overall".
The bug seems to be about the processor leaving speculatively read privileged data in some of the caches, even if execution failed [1].
If so, clearing all caches upon a failed privilege check sounds like something within the capabilities of microcode
and without unreasonable performance penalties.
Unfortunately, that would not explain the complex in-kernel fix...
EDIT: what remains in cache is not "speculatively read privileged data" but more "unprivileged data whose address is correlated to speculatively read privileged data". Retrieving later such address allows one to infer what the privileged data was. Still, the point about clearing all caches as countermeasure holds...
