I thought that the reason why Fedora was chosen was because it was what the developers were most familiar with.
The frozen state of dom0 (no direct update) and the QubesOS build infrastructure make a supply chain attack impossible (as long as you trust the developers to know what they’re doing and not being malicious).
And for the ~1000 packages that come with, each package is fairly minimal, reviewed by independent people, and more and more of these packages are being built with protection against supply chain attack in mind.
That, in addition to the fact that QubesOS is secure by compartmentalization (and dom0 being isolated from network devices), and its peculiar architecture means that malware/supply chain attack not made directly for it won’t impact the system integrity. Or as @solene put it :
As the project is Open-source, we can expect reasonable security against custom-made malware and supply chain attack.
This is absolutely false, as it is with any Open-source project. If you think that QubesOS doesn’t meet your threat model requirement, you can fork/audit the code and make it your own.
It seems obvious that if you can’t trust Fedora, you shouldn’t use it. But QubesOS’ use-case is specific and allow to only have to trust to Fedora up to a certain point, being that while it’s not perfect, I can trust that as long at it doesn’t have network access and as it is reviewed and tested by the QubesOS team (and the users too). Still “reasonably” secure IMHO.
And as for the bloat, this is a matter of opinion. I use KDE Plasma, so I don’t view the supplementary package as bloat.
I do think this is kind of off-topic, if you feel the need to continue this topic we should fork or exchange privately on the matter (and I would be glad too) ! 
I’ve heard of Nanos before and I’m glad there’s some lead to combine them with QubesOS.
Regarding dom0 minimizing or services/appvm minimizing, if you have some code you’re working on I’ll be honored to contribute. I am looking forward for this in QubesOS.
