Even if sandboxing was thought about back when Linus was porting Unix, it would have been extremely slow as processors and ram was very limited back then. If we could go back in time and give them ridiculously fast processors and effectively unlimited ram like we have today, I'm sure Linux and Windows (er, DOS) would look quite different, and be much slower.
Just look at how slow mobile OS's are, despite being on ridiculously fast hardware. My Palm Pilot in 1998 felt faster and more responsive than most devices today. Android devices essentially require a human to manage the memory because starting just a few apps uses almost all of it. Even iOS devices can only run a few apps before it starts killing things. Sandboxing has an extremely high cost (with not much to gain), so high that even on modern hardware you start running into physical limits very quickly: memory, disk space, and processing power.
Until we can properly share resources in sandboxed apps (or increase the physical limits of the hardware) to a certain point, it just doesn't make sense to only be able to run a few things on a desktop machine.
Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty directory followed by setuid() to "nobody". If that process needs file access, fork() a broker process before the chroot() that funnels file descriptors over an unix socket to the sandboxed process. The broker strictly checks file access permissions of course or could even present the file open dialog to the user.
This is next to no overhead in many cases (keep in mind you'll stat/open/mmap a bunch of .so's anyways on startup), except for the fork() maybe. And that can be fixed by proper sandboxing API's by the OS.
The problem is that these OS's give the processes to much permissions in the fist place (access to all the user's files, ...).
In theory, sure.
In practice, when Ubuntu added a sandbox to the calculator it started taking longer to start than Eclipse. Took them about 4 years to fix it.
Sandboxing and virtualization existed in mainframes and micros already for decades, and were originally made available in UNIXes like Tru64 and HP-UX Vaults.
Even simple optimizations like shared caches fall afoul of proper isolation. In the past browser caches could be abused to find out if a user frequented specific sites just by checking how long it would take to request a site specific resource. Result: no more shared caching, all resources had to be loaded for each site separately.
Any reasonable representation of its color would classify the Sun as white, except when comparing it to other stars, where the small differences matter a lot.
Please no. There are valid reasons to NOT sandbox, and in Windows there is sandboxing in default (windows store apps) and there are often issues with those versions of the software. For example, Slack downloaded from the windows store uses 30-40% of your CPU while idle, but not when installed from their website.
Even in Linux and using the Snap sandbox (ubuntu), there are significant issues when trying to access globally available software, which can be extremely hard to support and diagnose.