On a personal machine, it's perfectly reasonable to set mitigations=off - the only place where I run untrusted code is the browser, and browsers had mitigations very early on.
Browser mitigations are about protecting other parts of the browser from JS. Attacks against the kernel are intentionally left out of scope of these mitigations on the assumption that kernel mitigations will handle both JS->kernel as well as any other user process->kernel.
Those cache attacks rely on accurate timing because the method of data exfiltration is faster access to array members that were cached in a speculative access.
By fudging the time (JS doesn't need ns or even µs accuracy) those issues are pretty much solved.
That's not true...at all. There are amplification techniques which work in JS and wasm that amplify a cache eviction into an over 1s delta [1]. Trying to restrict timing as a mitigation has been known to be ineffective since 2019, a bunch of people at Google who worked on the mitigation in Chromium wrote a paper [2] saying as much. Site isolation is the chosen mitigation because it actually works.
