And this is exactly a big reason I don't trust the X.509 PKI. You have a short list of organizations that one screw-up can potentially gravely damage the whole infrastructure. At once. It doesn't even need to be a CA that you have a certificate from, it can be an unrelated CA that say, has had their keys compromised or audits underperformed, etc. Hence the DigiNotar incident or the COMODO or CNNIC incidents (The latter of two did not result in any revokations of trust despite violations of the public trust!).

X.509 works best internally within organizations or among small groups of organizations where everyone knows the policies and roles, knows who has the keys to each castle and the like and damage isn't likely to undermine all public communications. However with the PKI as it's currently designed, there's no real mechanisms at all in place to constrain damage. Browser vendors talk about name constraints (e.g. restricting a government actor to issuing certificates for their TLD, like there was discussion to restrict CNNIC to .cn) but usually discussion of that falls flat when it matters the most as it'd rock the boat too much.

In cases like this, where Microsoft are themselves both the auditee AND auditor. Of course they won't revoke their own trust or punish themselves in any meaningful manner. The audit documents in this case are a part of a security theater as nothing will come to pass if they fail to obtain the documentation. Sure they'll have a big fat "F" on their audit, but they cannot revoke trust in themselves without breaking too much infrastructure (driver signing, their TLS services, etc). Likewise the public can't reasonably remove their certificates either. They're too big to fail.

As it stands, the X.509 PKI is no longer about public trust, it's about the imposition of trust. Browser/OS vendors have seen to that.