Their point is untrusted code can still have private info (I don't want a random website to be able to steal my private key or my info like credit cards or password in other tabs), so you need a new core for each website, which is obviously impractical.

Unfortunately, being slow is just not acceptable in a decent portion of scenarios. Web developers won't start writing 5x faster sites, and cloud providers won't like needing 5x more hardware to serve the same amount of virtual CPU performance. (5x being my random guess of the performance decrease from losing speculative execution & co; it'd likely be even worse, especially combined with the fact that manufacturers would have to design a completely new chip)

They need to be in different trust zones unless your willingness to enter a credit card into any website means you’re willing to allow every other website you may be visiting to observe that input. Ditto viewing bank information etc.

That’s the point: you can’t just pile every website into the same zone, and if you did pile them into the same zone, then using a different password for x.com and y.com is to some extent pointless because x can observe y’s password input and vice-versa.

(disregarding the fact that in current computing architectures “just put all the untrusted stuff on one core” is probably an insufficient solution due to shared caches anyways, no indeed nothing in this attack requires “sharing a core”)