When that's what you're working with, you're limiting yourself quite a bit in terms of adding new security solutions. At best you'll be at least a decade behind the innovators in security who aren't afraid to build new stuff from scratch and break the old stuff.
Making security the primary goal of your operating system would be nearly as perverse as making swapping the primary goal of your operating system. The primary reason security seems special here is that we do have working swapping in our operating systems, but we don't have working security.
Nevertheless, if you try to add virtual memory to an operating system that was designed without knowledge of how such a thing could work (like nearly all 1960s operating systems) it is going to be pretty rough going! Today, security is where virtual memory was 50 years ago.
Qubes is interesting especially because it doesn't break compatibility with everything else.
I mainly consider solutions like Qubes to be for preventing accidental leaks, containing damage from regular malware, and making recovery easier. Much like the Compartmented Mode Workstations and MILS virtualization that came before it.
Real, more-thorough security will break compatibility or take a huge performance/functionality hit. Was true in any system designed to high assurance or surviving NSA pentesting. Will be more true for whatever supports legacy applications on today's more complex, leaky ISA's/API's. CheriBSD is closest thing to an exception but I don't even trust its monolithic parts due to how attacks can jump around in a system. Nizza Architecture on non-Intel, security-enhanced processors is best model for now given we can at least isolate security-critical apps into their own partitions on tiny TCB's. No mature FOSS implements that, though.
So, regular malware defence with Qubes, etc and energy-gapped systems + KVM's + guards for high-strength attacker defence remain the options.