Noting that they have deliberately added as little code as possible to dom0 to minimize the risk of introducing bugs or attack surface and quantifying it in service of their point is a sensible way of effectively conveying how they're approaching the problem. You attempted to use the same thing as a tool by which to make comparative value judgement, like seeing someone using a hammer to drive a nail and then attempting to use a hammer to drive a screw.

You also continue to shift the goalposts on things which I trust is not from malice but a hazy grasp of some basic fundamental concepts. You've already had it explained to you by people much more qualified than I how the Librem 5 has some entirely closed-source components running woefully outdated firmware, but now it's about celebrating something else entirely.

"Disabled and neutralized" IME is still IME that's highly privileged hardware running a closed-source operating system outside of your ability to monitor it. By the standards of evaluation you set in other comments baselessly criticizing Pixel hardware, you should object all the more to the x86 architecture, even with your ultimately insufficient attempts to reduce harm. The hand-wringing over the possibility that Google has embedded a still-undiscovered way to exfiltrate data from their phones even when running GrapheneOS, is misguided and unfair at best, and if nothing else you should be consistent in your application of these principles.

I trust I shouldn't need to cite every point you repetitiously make in order for you to stop complaining that I'm not limiting the scope of my reply perfectly to one particular comment of yours, as if this is some kind of contest of form.

If you kept current or really spent any time at all researching XSAs you'd know that its shared memory architecture alone has resulted in numerous XSAs, some of which could very much apply to your threat model. Hardware MTE would go a long way to mitigating that, which Pixels have. In the hypothetical scenario of Qubes OS running on more secure hardware than even your home brew situation, that would be a significant improvement over the status quo which you say you can't even imagine. You're defining your threat model overly narrowly by excluding all kinds of relevant factors and then declaring it wholly met. That's not how this stuff works.

If, after all this, you still can't imagine how Qubes could be improved upon for your particular threat model (having passwords in a vault appVM exfiltrated) after hearing just a couple hypothetical benefits of running it on more secure hardware, it's unsurprising you can't recognize the comparative advantages of GrapheneOS and instead want to rely on things like counting lines of security code because you once saw someone else do it in a different context.

My goal here is not to change your mind, that part is up to you and you've already had one of the finest minds in the field address your issues point by point elsewhere (that was a fun surprise to see). My goal is to reduce the ease with which you can continue to filibuster people into moving on with their lives so you can then continue making the same unjustifiable claim that nobody ever offers a meaningful explanation to you when you merely ask simple questions about the benefits of the project. Unstoppable Force Meets Argumentum ad nauseam.