This question has been revised & clarified significantly since the original version.

If we look at each trusted certificate in my Trusted Root store, how much should I trust them?

What factors should be taken into consideration when I evaluate the trust of each Root CA for potential removal from my local store?

More Information:
If a CA issues a certificate to an improperly validated party, then that causes all machines that trust that CA vulnerable to MITM attacks.  As a result all CA's stringently validate the requester of a given SSL certificate request to ensure the integrity of their CS chain.

However, a large part of this CA verification process is subject to human intervention and provides opportunities to issue a cert to the wrong party.  This may be done by CA operator error, government demands, or perhaps the coercion (bribe) of a CA operator.

I'd like to learn more about which default CA's are more likely to issue certificates to the wrong party.  I intend to use this information to advise users to remove that CA from their Trusted Cert Store

Examples:
Suppose the government controlling a particular CA wants to assume the identity of Microsoft.com, and demands an exception to the CA's verification process.  That government then also requires the secrecy of this exception be maintained.  The generated key pair would then be used in a MITM attack.

Windows Azure Default Trust

Windows Azure supports 275 CA's as shown in the following link.  Depending on the use of the particular CA, some of those CA's may increase the surface area of a particular attack.  In fact this may be technically required to make some applications work correctly.

Amazon Default Trust

(not available) Please share links to Amazon, Google, and VMWare's default CA list if you come across them.

Mozilla

A list of all certificates and audit statements is available.

Apple iOS

List of all iPhone root certificates as mentioned in this #WWDC2017. video

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. 

Tunisia is another country that runs a widely-trusted CA, and there is also good documentation of the actions of their government to invade privacy: The Inside Story of How Facebook Responded to Tunisian Hacks - Alexis Madrigal - Technology - The Atlantic

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:


ImperialViolet - DNSSEC and TLS
Network Notary - Perspectives : Improving SSH-style Host Authentication with Multi-path Network Probing
Google Online Security Blog: Improving SSL certificate security


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

Update 6 Several Certificate Authorities have been caught violating the rules.  That includes the French cyberdefense agency (ANSSI), and Trustwave, each of which was linked to spoofing of digital certificates.

Update 7 Yet another set of "misissued certificates", via the  Indian Controller of Certifying Authorities (India CCA) in 2014: Google Online Security Blog: Maintaining digital certificate security

See also the question on Certificate Transparency which looks like a helpful approach to discovering bad certificates and policy violations earlier.
