> What I really want in Linux is good defaults that treat users as infants playing with scisssors.
You're not alone! Distros have been trying to fix the "user got pwned so attacker basically has root" problem for a while now.
One approach people tried for a while was the SELinux/AppArmor method. This works great for server daemons but there's nothing for user facing applications. Docker and other types of containers replaced most of that approach as far as I can tell, and SystemD replaced the parts that couldn't easily be containerized.
On the user facing side, Flatpak and (sadly) Snap have become mainstream as ways to limit exposure. You can drop a file into ~/Downloads, but if you exploit the browser you won't be able to access ~/.ssh/ because of sandboxing constraints.
There are problems to this approach. First of all, nobody is going to rewrite thirty years of software to work with the latest and greatest New Thing. Old stuff will need to work the old way or will need to be wrapped in some kind of compatibility layer that will be annoying to deal with because it requires unsealing the secure outer shell.
Then there are the users. Linux users hate change of any kind. There are still many vocal people who will curse out anything that contains systemd. Their unique preferences include storing their personal files in some kind of recursively linked directory structure operating from ~/.myhome/tmp using a bespoke encryption algorithm and if you dare touch it, you might as well be Micro$oft itself. These are a tiny minority of any community, but they'll crawl out of the woodworks in any discussion of your proposal.
There's also actionability to take into account. If I'd get some kind of LKM or auditd popup on my laptop, I would have no idea what to do next. Is it bad if something is touching /var/run/udev0.elf? Is that just some part of my system I never knew about? Whatever alerting system you build, you'll need some kind of decision making process that clearly labels what each message means, why that's bad, how to verify that this is actually a problem and what steps to take next. That's an immense documentation task nobody is going to want to undertake.
I like the general direction Linux is taking. Sandboxing applications makes sense and Flatpak seems to be here to stay. systemd is making restriction privileges very easy (if only distros would actually use it...) and using Docker for deployment (as non-root users) seems to be taking hold over the old ways.
There are still things to be gained, like proper Linux antivirus engines for end users. ClamAV is nice but if it doesn't come preinstalled with live file access, it may as well not be there at all.
The monitoring tools are already there. Everything is stored in journald and the various other log files, ready to be scooped up. Set up FileBeat and Kibana (or a more dedicated dashboard) and you've got more alerts and telemetry than you could ever wish. There are tools out there that try to be a security log monitor, but many of them end up being unmaintained and lacking support of that one specific tool you really need it to analyze.
Windows suffers from many of the same issues regarding "well if they've got root you're already screwed". If you've got NTAUTORITY\SYSTEM, all of your fancy protection mechanisms quickly fall apart. Large parts of Windows' security layers are set up to prevent attackers from gaining privileges and most of them are ineffective with default settings. UAC bypasses can be found everywhere unless you put the UAC slider all the way to the top and/or log in as a non-administrator user. Driver signing is a bother, but loading drivers with known exploits is easy and basically hands you the same privileges. There's virtualisation based security and the VM based Windows sandbox thing, but that's not necessarily going to solve anything unless the attackers are after something stored inside those layers.
The difference is perhaps that Windows has you operate with admin privileges much less often (although you shouldn't underestimate all of the hidden elevation with the UAC defaults!) compared to Linux.