Update 5 The root problem (heh) with the CA model is that in general practice, any CA can issue certs for any domain, so you're vulnerable to the weakest link. As to who you can trust, I doubt that the list is very long at all, since the stakes are high and security is hard. I recommend Christopher Soghoian's post on the subject, which clarifies the various approaches that governments around the world have used to get access to private user data - whether by directly demanding it from companies that operate cloud services, via wiretap, or increasingly now via CA coercion or hacks: slight paranoia: The forces that led to the DigiNotar hack.
Here I provide some specifics, and end with links to some potential fixes.
In 2009, Etisalat (60% owned by the United Arab Emirates government), rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail, so it can hardly be considered trustworthy. But it is in a lot of trusted CA lists: http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars
Update 1 See also an example of a successful attack, allegedly by an Iranian named ComodoHacker, against Comodo: Rogue SSL certificates ("case comodogate") - F-Secure Weblog. F-Secure notes that Mozilla includes certificates issued by CAs in China, Israel, Bermuda, South Africa, Estonia, Romania, Slovakia, Spain, Norway, Colombia, France, Taiwan, UK, The Netherlands, Turkey, USA, Hong Kong, Japan, Hungary, Germany and Switzerland.
Mozilla notes another questionable practice to watch out for: CAs that allow an RA partner to issue certs directly off the root, rather than via an intermediary: Comodo Certificate Issue – Follow Up at Mozilla Security Blog.
See also more detail, including speculation about the claim of responsibility by a lone Iranian hacker Web Browsers and Comodo Disclose A Successful Certificate Authority Attack, Perhaps From Iran | Freedom to Tinker
Update 3: Another successful attack seemingly also by ComodoHacker was against the DigiNotar CA. Their website was compromised starting in 2009, but this was not noticed until after DigiNotar had also been used in 2011 by Iranians to sign false certificates for the websites of Google, Yahoo!, Mozilla, WordPress and The Tor Project. DigiNotar did not reveal its knowledge of the intrusion into its site for over a month. See more at DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model | Freedom to Tinker.
I'd guess that the range of vulnerability of various CAs varies pretty widely, as does their utility. So I'd suggest refocusing your strategy. When you can narrow it to specific assets you're trying to protect, just delete all CAs except those necessary for using those assets. Otherwise, consider eliminating the CAs you judge to be most vulnerable to those who care about your assets, or least popular, just to reduce the attack surface. But accept the fact that you'll remain vulnerable to sophisticated attacks even against the most popular and careful CAs.
Update 2: There is a great post on fixing our dangerous CA infrastructure at Freedom to Tinker: Building a better CA infrastructure
It talks about these innovations:
Update 4 One of our IT Security blog posts in August 2011 also covers the case for moving to DNSSEC: A Risk-Based Look at Fixing the Certificate Authority Problem « Stack Exchange Security Blog