Because there's already UNIX file permissions which prevent applications to reach places they shouldn't. Confine a daemon to its own user, chroot it, and it's a sitting duck in its own universe.
You add more layers with cgroup/AppArmor/SELinux in Linux, Jails in FreeBSD, unveil on OpenBSD, etc.
You harden as much as necessary. Not "drowned by default".
> Because there's already UNIX file permissions which prevent applications to reach places they shouldn't
Right. Just set up a separate user for Firefox using a single unprivileged command from your user account or a few clicks in your DE, then launch Firefox as that user using another single command or click. Being subordinate to your main user account, the Firefox user's files and directories can easily be managed from your main user and you can move files between subordinate users using just an (unprivileged) chown or chgrp. Accidentally launching applications as your main user is not possible and the system strongly encourages you to create separate, subordinate users for all your applications and is designed from the ground up to make this simple and it works out of the box.
Oh wait, that's not even remotely how any of this works. On a workstation, the "user account" is an almost completely useless concept (as set up and implemented in reality). That's why we have jails/namespaces/etc. Hacks that are piled on top of the useless mess of "user accounts" (all running as the same user, on workstations) trying to solve the same problems, but ultimately failing at providing any kind of comprehensive solution with a coherent vision. Software cannot take anything for granted anymore. Anything that looks like a writable file could be a read-only bind mount. Any mundane syscall could get it SIGKILLed for no reason other than that somebody forgot to add it to the whitelist. But from the user's perspective, there's no reasonable level of security by default.
Considering how we use jails/namespaces and other similar technology, your analogy sounds off. First of all, security is always set up in layers. A different user and chroot doesn't exclude the use of jails, or other kernel level security systems like AppArmor/SELinux. They are layered on top of each other as necessary.
Also, namespaces is not solely a security mechanism. Yes it allows isolation, but it allows resource limitation, too. So you can partition your system to slices and show a particular set of resources to an application (I'm sure you're way more knowledgeable than me in that regard).
On the other hand, security starts with application itself. Then you start to add extra containment barriers if you don't trust the software in question.
What I understand is our realities are completely disparate, and this is not how we hold the mechanisms I talk about. This might be due to the environment each of us live in, or due to our requirements, I don't know.
But, what I know is, the state of security is not as bleak as you portray, and necessity is mother of invention. Except SELinux, AppArmor, and FireJail all of the technologies we talk here are essentially built as virtualization, or virtualization-like technologies. They bring additional security as a secondary effect, and they're good at that.
> Software cannot take anything for granted anymore.
This is why we have stat calls, defensive programming, APIs and exception handling. The first rule of system programming is to never take anything for granted.
I have reached to the end of the time I have for today,
You add more layers with cgroup/AppArmor/SELinux in Linux, Jails in FreeBSD, unveil on OpenBSD, etc.
You harden as much as necessary. Not "drowned by default".