> Well designed security models don't sell computers/operating systems, apparently.
Well more like it's hard to design software that is both secure-by-default and non-onerous to the end users (including devs). Every time I've tried to deploy non-trivial software systems to highly secure setups it's been a tedious nightmare. Nothing can talk to each other by default. Sometimes the filesystem is immutable and executables can't run by default. Every hole through every layer must be meticulously punched, miss one layer and things don't work and you have to trace calls through the stack, across sockets and networks, etc. to see where the holdup is. And that's not even including all the certificate/CA baggage that comes with deploying TLS-based systems.
> Every time I've tried to deploy non-trivial software systems to highly secure setups it's been a tedious nightmare.
I don't know exactly which "secure setups" you are talking about, but the false equivalency between security and complexity is mostly from security theater. If you start with insecure systems and then do extra things to make them secure, then that additional complexity interacts with the thing you are trying to do. That's how we got into the mess with SE Linux, and intercepting syscalls, and firewalls, and all these other additional things that add complexity in order to claw back as much security as possible. It doesn't have to be that way and it's just an issue of knowing how.
If you start with security (meaning isolation) then passing resource capabilities in and out of the isolation boundary is no more complex than configuring the application to use the resources in the first place.