One reaction to my entry on how Certificate Transparency logs let us assess CAs is to note that this only applies for TLS certificates that are sent to CT logs. As far as I can tell, the CA/Browser Forum baseline requirements (version 1.8.0 right now) don't seem to require that a CA do this, so it's not absolutely mandatory. It's only required if you want browsers to accept your TLS certificates, or if a CA promised to do this in their documentation of their practices.

(Not following their own published rules is what got Let's Encrypt in trouble when they issued TLS certificates that were valid for one second longer than expected. The TLS certificates were otherwise in conformance with the Baseline Requirements, and part of LE's fix to the issue was to change what they said about their practices.)

Thus in theory you could have a non-browser Certificate Authority that issued TLS certificates without logging them to CT systems. One perfectly valid question is whether we care about such a CA for TLS certificate usage questions, since it's clearly a relatively niche usage (and by definition, browsers changing what they accept doesn't affect its certificates). But another practical question is how its root certificates would wind up widely available in trust stores. The reality of today is web browsers are the dominant source of CA root certificate trust stores, and they run their root stores primarily for themselves (and for web TLS in general).

There are four major web browsers left; Chrome, Safari, Microsoft Edge, and Firefox. The root certificate trust stores on macOS, iOS, and Windows are almost certainly strongly influenced by their respective browsers; it seems unlikely that either Microsoft or Apple would accept a new CA root certificate into them if it wasn't intended for web usage and wasn't going to routinely log its certificates to CT logs. Almost all Linux systems use Mozilla's CA roots (see for example Fedora) as their trust stores, and it seems relatively unlikely that Mozilla would accept a non-web TLS CA into that store. This leaves Android, which I believe basically uses Chrome's certificate store these days; since Chrome is a big driver of Certificate Transparency, I suspect Google wouldn't be any more enthused about a non-CT Certificate Authority.

The reality of life is that maintaining a good, well curated list of CA root certificates is a lot of work and doing it well requires you to have heft and influence. Mozilla (the least influential of the remaining four) can still get Certificate Authorities to pick up the phone and admit to problems; Red Hat, Debian, or FreeBSD might be another matter. In practice, this implies that maintaining your own root CA list means either rejecting some CAs that (eg) Mozilla considers still acceptable or accepting CAs that can't satisfy Mozilla or aren't interested in doing so (and hoping that they're still trustworthy).

As a corollary, I don't think there are very many organizations that could effectively create and maintain an independent CA root trust store. I believe that to do this well, you must be able to threaten CAs with being cut off from something you are the gatekeeper for, and there are very few organizations that are big enough gatekeepers for TLS to make this an effective threat. Browsers are the largest gatekeepers (that's why they're driving TLS now), and so I don't believe it's an accident that they've wound up maintaining effective CA root trust stores.