This is classic cat and mouse. Once most AV vendors and OSs support this, they will find a different way. In other words, increased complexity for a temporary relief.
It's really is about time that OS vendors to start looking at this problem differently. There is a part of the system that is for the system only, and a part that is for the user. Keep the two seperate, 100%. Each and every program should be in their own little sandbox, so any compromises are confined to that sole program.
Sandboxing this way will not make the problem go away, but it will significantly reduce the attack surface that needs to be hardened to prevent a random exploit to be used to jump to a systemwide exploit.
For most programs to be useful the need access to data/resources outside of that sandbox. The challenge is making that work without being super annoying to the user.
That is perfectly fine. Finding that balance of what to make available and what to keep locked away, is what the sandbox is all about. My point still stands however, the attack surface is significantly reduced.
The problem with these "trusted" and "secure" systems is not that they restrict what the computer can do. The problem is when only the manufacturer gets to choose what is allowed and what is not.
For example, a secure boot system where the root keys can be set by the user would be perfectly fine, even with the FSF. (Yeah, that opens a whole can of worms, but original Chromebooks showed that you can have a physical "dev mode" switch and still keep unknowledgeable users safe by default.)
I'm a developer (web / frontend) and I have yet to come across a situation where Apple's sandboxing feature restricted me or any of the application which I use. The users who are negatively impacted by sandboxing are a minority. A vocal minority, but a minority nonetheless.
We use other applications besides the web browser! Those which run in the terminal (vim, emacs, nodejs, ruby, ...) and also full desktop applications (Photoshop, Sketch and whatnot).
It's really is about time that OS vendors to start looking at this problem differently. There is a part of the system that is for the system only, and a part that is for the user. Keep the two seperate, 100%. Each and every program should be in their own little sandbox, so any compromises are confined to that sole program.
Sandboxing this way will not make the problem go away, but it will significantly reduce the attack surface that needs to be hardened to prevent a random exploit to be used to jump to a systemwide exploit.