I had a thought.
With QubesOS seemingly being the most secure distro ever, there doesn’t seem to be any reason to rely on any other security or privacy-focused OS (save for maybe Tails or a hacking distro like Kali Linux).
But what if anybody would rather pick a BSD operating system such as OpenBSD, HardenedBSD or the upcoming HypberbolaBSD?
Maybe not necessarily replace Qubes but maybe use as a secondary OS in a dual-boot system or something?
What would be the merit in that?
OpenBSD developer here, I’m using Qubes OS on my workstation because it gives me compartimentalization that OpenBSD can’t provide, and I can also run Linux programs which I often need for work (like using containers or proprietary software).
just use the right tool for the job.
Dito. And in addition: „secure“ is rather a label than a stable distinct attribute.
Some people mean by „secure systems“ security against attacks by $EVILGUYS, some tamper-proof installation against curious users, high availability in case of desaster, trust by validation etc. That‘s why security in a wider perspective is rather a concept to solve special problems depending on individual risk scenarios.
Such concepts are also very (very!) rarely based on a single product/OS/technique.
OpenBSD has more strict policy for bugs and front-edge software. Also BSDs have own kernel, that can be more secure than Linux which is currently huge and has too much code for security audit or anything to keep in control.
But, unfortunately, one should admit, that FreeBSD and other BSDs lost the battle to GNU/Linux completely. Gigantic monolith Linux kernel provides better hardware support (~drivers), which is crucial for most users. And all users who run steam or similar stuff would choose GNU/Linux, too. So, BSDs, unfortunately, are going to extinct further, imho.
There are some bottlenecks when using Qubes, ie. usb transfer speed. You probably won’t have in more standard system. So when you find such bottleneck is blocking for a task at hand ; booting on the other system will sometimes help.
About hardware with a single, CPU-embedded GPU, I never could achieve to share graphical power to domU. To play games on Steam, I need to run another system. Hardened standard OSes won’t probably have the issue. Having another GPU could also beat the issue with PCI pass-through.
Virtualization is also one use case I need sometimes to run (at least test) on another system than Qubes : because it relies on Xen, using virtualization inside of an appVM is necessarily nested.
While nested virtualization is mostly supported by Xen, there are some cases you wont get the expected behaviors. And hard to say if the issue comes from nested virtualization itself or my own config : I would boot a standard system to check.
Finally, management overhead is sometimes kind of overwhelming, at least more than on regular systems. When you are not willing to spend extra time and tears to maintain it, Qubes may not be not the best option. And adding on top the maintenance of other systems on multi-boot 
, could possibly turn you maintenance slave of your systems 