I think that “trust nobody” is an oversimplification of what is stated. Let’s break it down:
We would like to remind you that Qubes OS has been designed under the assumption that all relevant infrastructure is permanently compromised.
This is saying that Qubes OS is designed to operate under a certain assumption. What is that assumption? It is the assumption that “all relevant infrastructure is permanently compromised.” In order to understand this statement, we have to answer a few questions:
- What does “infrastructure” mean?
- Which infrastructure counts as relevant here?
- What does “compromised” mean?
Let’s look to the next statement for answers:
This means that we assume NO trust in any of the servers or services which host or provide any Qubes-related data, in particular, software updates, source code repositories, and Qubes ISO downloads.
The fact that this sentence starts with “This means that we assume…” shows that it’s here to clarify the previous statement. In particular, it clarifies and explains the assumption, mentioned in the previous sentence, under which Qubes OS is designed to operate.
“NO trust in any of the servers or services which host or provide any Qubes-related data” helps to answer the first question (“What does ‘infrastructure’ mean?”). We see here that “infrastructure” refers to things like servers or services which host or provide data. These are the types of things we’re referring to when we say “infrastructure.”
The phrases “Qubes-related data” and “in particular, software updates, source code repositories, and Qubes ISO downloads” help to answer the second question (“Which infrastructure counts as relevant here?”). We see that the relevant infrastructure is infrastructure used to host or provide Qubes and domU OS software updates (i.e., package repositories), Qubes source code repositories (e.g., GitHub), and Qubes ISO downloads (i.e., download mirrors). These are examples of infrastructure that count as relevant in the phrase “relevant infrastructure.”
Given this context, the answer to the third question ("What does ‘compromised’ mean?) is now pretty clear. It’s referring to scenarios in which someone uses the infrastructure to do something bad. For example, someone could hack into GitHub’s servers and try to mess with our source code, or a rogue employee at GitHub could do the same. We protect against this by cryptographically signing all of our code. This way, even if a hacker or rogue employee messes with our code on GitHub, we’ll always be able to tell, and we’ll know not to trust it. In other words, we don’t treat GitHub as an authoritative source for our code or as the source of truth for anything.
Similarly, any of our download mirrors could be compromised. When you try to download a Qubes ISO, it could instead serve you a fake Qubes ISO with malware inside. We protect against this the same way, namely by cryptographically signing Qubes ISOs. By verifying the signature on your Qubes ISO after you download it, you can determine whether it’s genuine or a forgery, so you’ll know whether to trust it.
What about software updates from package repositories? Same thing. Cryptographically signed. You’re probably beginning to see a pattern here. 
We call this general philosophy or approach “distrusting the infrastructure.” Here is our FAQ entry on it:
What does it mean to “distrust the infrastructure”?
A core tenet of the Qubes philosophy is “distrust the infrastructure,” where “the infrastructure” refers to things like hosting providers, CDNs, DNS services, package repositories, email servers, PGP keyservers, etc. As a project, we focus on securing endpoints instead of attempting to secure “the middle” (i.e., the infrastructure), since one of our primary goals is to free users from being forced to entrust their security to unknown third parties. Instead, our aim is for users to be required to trust as few entities as possible (ideally, only themselves and any known persons whom they voluntarily decide to trust).
Users can never fully control all the infrastructure they rely upon, and they can never fully trust all the entities who do control it. Therefore, we believe the best solution is not to attempt to make the infrastructure trustworthy, but instead to concentrate on solutions that obviate the need to do so. We believe that many attempts to make the infrastructure appear trustworthy actually provide only the illusion of security and are ultimately a disservice to real users. Since we don’t want to encourage or endorse this, we make our distrust of the infrastructure explicit.
Now that we understand what the disclaimer means, let’s take note of what it does not say. It does not say that we place no trust in upstream projects that we rely on, e.g., Xen, Fedora, or Debian. It also does not say anything about the infrastructure that those upstream projects use, own, or rely on. It says that we place no trust in “servers or services which host or provide any Qubes-related data.” It does not say anything about servers or services that host or provide Xen-related data, for example.
In other words, we do not try to police other projects or force them to abide by our standards. Even if we wanted to, we could not do that. We can’t force anyone else to do anything. All we can do is decide who we will trust, because we can’t do everything ourselves. For example, we can’t create and maintain the Linux kernel by ourselves. We can’t create or maintain Xen by ourselves. Those are whole projects in themselves, and they’re vastly larger than the Qubes OS Project. This is why “trust nobody” is unrealistic.
If we tried to do everything by ourselves, it would be evidence that we don’t really understand the nature of our own undertaking. As an analogy, it would be as if a small local militia in some town were to say, “We don’t trust the national military, so we’re going to defend the country all by ourselves.” Everyone can immediately see that it’s absurd and delusional for a small group of people with hand weapons to hope to defend against tanks, artillery, aircraft, warships, and ICBMs. Similarly, it would be absurd and delusional for us (the Qubes OS Project) to say, “We don’t trust the Linux Foundation, the Xen Project, the Fedora Project, the Debian Project, or anyone else, so we’re going to defend against cyberattacks all by ourselves.”
Now, you might say, “Well, I wouldn’t expect you to write all the code yourself to replace those huge projects, but couldn’t you at least check all the upstream code you use?” No, this is still a herculean undertaking that would be completely unrealistic for a project of our size. After all, there are multiple entire operating systems inside of Qubes OS, plus a hypervisor. Those gigantic upstream projects can barely even check all of their own code. Moreover, since most projects are not security-oriented, they probably never check their code in the way security researchers would (which is probably part of the reason projects and companies have bug bounties and why independent security researchers often discover major vulnerabilities).
“Okay, fine,” you might say, “but you should at least just check the upstream code that’s included in the Qubes TCB, right?!” At first glance, this might seem like an eminently reasonable request. Of course, we should check all the code in the Qubes TCB, shouldn’t we? After all, isn’t the whole point of Qubes to trust as little as possible? In theory, yes, but “trust as little as possible” isn’t the same as “trust nobody,” and in the real world, “as little as possible” is still quite a lot. Since I am not an expert, I asked @Demi about this. Here is what she said:
No. We do not even review all of the attack surface, such as Xen, Linux blkback, and Python’s regular expression library. There is even attack surface we have no visibility into, such as CPU microcode and USB controller firmware.
Reviewing the entire software TCB is only practical in certain embedded systems, and even there only because these systems are vastly simpler. If the entire TCB is 50,000 lines of code on a microcontroller, then one really can read the entire codebase in a reasonable amount of time, at least if one has access to all of the source code. In Qubes OS, the attack surface alone is quite a bit larger than that, and the TCB is many orders of magnitude larger – it includes Xen, Linux, and every other piece of code that runs in dom0, as well as the toolchains used to build that code. This is at least tens of millions of lines of code, and that is before one gets into the firmware, microcode, and other stuff that Qubes OS doesn’t even have visibility into, much less control over. Admittedly, not all of that code actually runs, but figuring out what does and does not is itself a nontrivial task.
In short, auditing the entire TCB is completely impractical, and auditing the entire attack surface would require far more resources than the Qubes OS Project has. If one wants to build a system people can actually use, one has to trust a lot of stuff.