(As usual, I must stress my lack of technical credentials and welcome any corrections)
The IDS that you mention and the IDS that I assume the thread is about seem very different–while I talk about off-the-shelf IDSes, which most people will have the ability to install, you seem to be describing something completely custom made for the purpose of detecting those who intrude Qubes OS dom0, as it involves dom0-specific positioning (and immutability that involves breaking dom0 isolation).
Now, I won’t dispute that such an IDS would be valuable and a net positive, assuming its creator can make a bug-free IDS that won’t end up costing her more than it’s worth, but if it was this important, the developers would’ve come up with some sort of bundled package already, but this would be an ineffective, ad-hoc solution for reasons you yourself have provided.
You raised a point that has come up before, which is that an intruder sophisticated enough to reach dom0 would be equipped to sneak past whatever was set up in the throne room. It may be argued that adding a diverse combination of defenses and detection --throwing as many obstacles in the attacker’s way as possible-- will increase the cost of attack and the likelihood of a trip-up, but the exponential increase in attack surface that comes with this is a very real cost, and is why I think one shouldn’t set aside the issue of attack surface, or else you’ll end up endorsing confused stances like this one, assuming by “securing” you mean installing IDSes and more:
Rather than rebutting individual points, it’s easier to write out my stance: domUs are assumed to be compromisable, hence the extensive compartmentalization, redundancy, and disposability; but the Qubes security model is built on the security guarantees that Xen represents–Xen is the bedrock of Qubes. If Xen were to be turned against the user, the Qubes security model turns to dust. If one assumes that dom0 has been compromised, assuming one hasn’t made risky changes to it, it is safe to assume that Xen has been penetrated and it’s GameOver; you’ve been owned. This is why it’s more important to secure domUs than it is to secure dom0, because its security is underwritten by Xen and Xen alone, and the way to attack it would be via the exposed domUs.
A dom0 that is breached is a symptom and not a cause. While detection is important, prevention and earlier detection is much more important, and those are done with domUs. The fact that detection of a breach of the throne room requires immutability (involving un-isolating dom0), and even then isn’t guaranteed, makes the benefits small compared to any costs incurred.
However, using the bedrock argument, one can also make the argument that since dom0’s only vector is Xen, one can afford to increase its conventional attack surfaces (assuming what you install doesn’t contain or create intentional or unintentional vulnerabilities). I’m not so sure about this part, and would be grateful if anyone could point out flaws in it or my stance in general.