You can control the CA certs that are download to a Windows machine, you even run the process manually if you wish, so that you're totally in control of what is "trusted" via certs. See here for more info.
Of course I fully expect those that have "trust issues" to manually inspect every byte of code (including the BIOS and the CPU firmware) that runs on their precious machines.
That isn't what I meant when I spoke about trust. I meant that if a cert is issued by someone like Verizon, Symantec or Comodo, you can have some confidence that at least some checks on the identity of the person applying were done and that it is likely that whoever is showing you that certificate is who they claim they are.
If you get a cert issued by a random CA from Eastern Bananistan that nobody has heard about before, it doesn't exactly inspire confidence that the rules were followed, even if their cryptographic chain of trust traces back to one of the major CAs.
Let's Encrypt is propagating its own root, but in the mean time their Authority cert is cross signed by IdenTrust, which is a major root known by all browsers.
As for "trust" well, in the old days when you paid hundreds of dollars for an SSL cert, they "verified" you by phone. It was automated, too. You'd get a call asking to state your full name and company (if applicable) which was recorded and (I assume) stored for the duration of the cert's validity. This was how VeriSign did it 10 years ago. That was literally all there was to it.
Now, Let's Encrypt uses the ACME protocol to actually verify you have control of the domain in question. You run the Let's Encrypt client *on your server* which uses Apache or DNS to perform a challenge response with *their server* for verification. Then the cert is issued.
That seems like much more verification than a 5 second automated phone call from VeriSign, to me. (Seriously, the $$$ SSL certs of old were mostly smoke and mirrors. I ran a big web hosting company from 2002 to 2008, so I know alllll about it.)