Browser vendors have already rolled out process isolation to handle this. So why would CPU vendors spend silicon on something userspace has already solved with the building blocks that are already supported?

In-process sandboxing by all appearances is simply dead.

As for "doing the same in ring 0 almost certainly isn't a big deal" no, very extremely no. If you let code run in ring 0 it has everything ring 0 can do, period. You cannot put restrictions on it, that's what spectre proved. Give code access to a process and it has entire access to that process. Similarly give something ring 0, and it has the entirety of ring 0.

Untrusted code goes in ring 3 in an isolated process. That's the security model of x86, and it's the only model that CPU vendors have any pressure to fix.

It's worse than what you're stating. Spectre is remotely exploitable with network packets (NetSpectre). The current state of the world isn't just fine with process level security, and the chip vendors are going to need to fix it, because ultimately you can exploit then if you control the data, not just the code. They have several options available to them, all of which also let's you run sandboxed untrusted code in the same MMU context as trusted code.

It is unclear if NetSpectre works in a real environment, but either way it's fundamentally similar to an IPC call and can be treated as such. As in, that's where you'd insert hardening boundaries.

Chip vendors have & will fix process boundaries. But nobody is talking about any sort of protection of any kind that would let in-process sandboxing work again. It's just not even on the table at this point.