SELinux is nothing but a maintenance burden for developers and users. There's a reason no major distro beyond the Fedora line that enables it by default, including the one I work one; it almost invariably frustrates users, has incomplete support for the workflows they use, and so they turn it off anyway. I literally turned off SELinux on my new ARM64 Fedora machine last week, because it prevented me from installing a third party binary (which I am a developer of.) That binary in turn needed its own ability to use namespacing support to sandbox applications (in a manner that works and offers enhanced security on any Linux distro, not just SELinux ones), etc. It's a non-starter.
> Since that’s generally believed to be the case, no sandboxing is necessary.
That's where you're wrong. It's necessary even if you believe it's not. It's been proven time and time again that this is the case and that the "belief" no flaws exist is wrong.
Sandboxing approaches that use techniques like namespaces, and capability security have become vastly, vastly more popular over the years on Linux, and they're going to keep getting more popular, precisely because they work where SELinux fails (that is, 98% of the running Linux systems and distros that actually exist). Browsers, WebAssembly, systems like Flatpak with "Portals" -- all of them have moved into capability-inspired and "component" sandboxing approaches, to achieve this level of security independent of the host operating system. If Chrome had decided to use SELinux instead of its own sandboxing approach, it's security model would be completely inferior to what it is today.
