You might perhaps have a setup where trusted users are running trusted code, can guarantee* a lack of malicious intent, and primarily want the user-and-process-segregation system to prevent a single failure of a single process from affecting anyone else.
You might conceivably have this in a corporate environment (I do).
For the vast majority of systems that do run untrusted code, including web browsers, this mitigation is probably appropriate.
Perhaps the word “might” here could be upgraded to “probably”?
You still want to run as a regular non-root user, possibly different users. The key difference to the mainstream use case is that you're looking to minimise the impact of bugs and failures, rather than manage security and combat malicious actors/code.
For this particular use-case, you might well consider that you don't need to patch for meltdown and spectre given the perceived risk/performance tradeoff for the current patches.
You might conceivably have this in a corporate environment (I do).
For the vast majority of systems that do run untrusted code, including web browsers, this mitigation is probably appropriate.
Perhaps the word “might” here could be upgraded to “probably”?
*for some arbitrary value of “guarantee”