Awesome! Any idea how much of that is attributable to LetsEncrypt and HTTPSEverywhere?
I ran into a local store taking credit cards awhile back, no TLS, weird, so I go to the store owner in person. I explain the problem and he insists that can't be the case, he's mad at me. "See! It's got a lock on the website!"... on the homepage. I direct him to the store and now it says Not Secure.
That did more to explain the situation than my attempt at TLS and HTTPS and Certs. He was able to call his web guy and say "It says not secure, Jerry! Fix it".
It was such a simple addition to (at least in Firefox) use the words Not Secure that it's crazy no one thought of it before.
Side topic, but I've been trying to explain to our terrible CFO for years that PCI / PCI DSS is a real thing. He thinks that's the type of regulation that only giant companies have to deal with.
Doesn't matter though, the reality for him was that customers saw a Not Secure and that was a problem. All the crypto, certs, forms, probability of issue, technical things didn't matter, just the perception.
Browsers couldn't have done that if https wasn't free and simple for servers.
Most of the major websites fast-tracked HTTPS shortly after that.
I can't count the number of times I've seen the extension page during sign-ups or logins. Oracle Cloud just triggered it the other day during signup and initial login. Most times when I email, asking why an email marketing link, or an embedded token-login email link sends me through an HTTP URL, the person on the other ends tells me they don't know and that's unexpected, or a result of out-sourcing their marketing/email/whatever.
In one case, their marketing mail provider supposedly just blanket intercepted all links and unknown-to-their-customers passed them through an HTTP redirect. Stunningly unprofessional.
At work, we use a paid certificate that is good for a longer period of time (normally a year). So that's one benefit to paying, I suppose.
As far as encryption technologies and security, the traffic encrypted by a lets encrypt cert is just as secure as the traffic secured by a paid-for CA signed cert.
(It's been a bit sinse I went through it but I think it may be as simple as a extra flag in the command to generate the inital cert)
Let's Encrypt could have just as easily generated certificates good for a year or more. But the point of Let's Encrypt is to force you to do this in an automated way, using scripts like you suggest.
You're not getting around anything. The choice was by design.
Sometimes I hear about people just looking for "SSL certificates" because somebody told them that they should have one, and search engines would lead them to those websites; probably that's how it still works.
LetsEncrypt signatures are now trusted by the browsers, so there's usually no need to pay for the service.
There are two halves to the first answer but they're both "Yes, Let's Encrypt is just as secure".
1. Most elements of TLS security have nothing whatsoever to do with certificates. This is easier to grasp in TLS 1.3 than earlier versions (all the encryption in TLS 1.3 is working before anybody sends any certificates anywhere) but it has always been true.
Even without certificates eavesdroppers can't see what was communicated, and nobody can change it en route between client and server. For these things even no certificate at all would be fine...
Certificates do add a vital thing though: Identity. A certificate from Let's Encrypt is a signed document from Let's Encrypt vouching for the identity of your site. Cryptography (with a "private key") lets you prove this certificate belongs to you and nobody else can do that. Without Identity somebody in a position to be an eavesdropper could just pretend to be you and intercept everything (a "Man in the Middle"). So even though it's a small aspect it's vital.
2. To go around issuing people with Certificates you need some way to know who is who. Until a few years ago there weren't many hard and fast rules about how to do this, and so a lot of rather dubious procedures were used by people who charged a pretty penny. Some of them would argue that charging validated the purchaser but that's not so smart, plenty of crooks are willing to spend money to make more.
So, Let's Encrypt actually helped write actual formal rules for how you can make sure you're issuing certificates to the real owners of the names they're certificates for. These are known as the Ten Blessed Methods, because there were once exactly ten of them and each is a method that the certificate issuer is allowed to use to do this Domain Validation. None of them are utterly foolproof, and there is ongoing work to further improve them or get rid of the least effective ones, but at least now there are written rules.
Having helped write these rules it should be no surprise that though they represent a significant tightening up of things for some of the incumbent for-profit issuers, Let's Encrypt was already doing everything required.
Partly this is actually helped by not taking money for certificates. Since Let's Encrypt doesn't make a profit from giving you a certificate, they've no incentive to do so unless they're sure.
Now: For the second part, I have written lengthy answers elsewhere, there are a lot of reasons you might pay somebody money. None of these reasons make Let's Encrypt any worse, and many of them are real niche cases, you'd know about it if you've hit those. Like if you make web sites for Nintendo's obsolete WiiU video game console - Let's Encrypt doesn't help you because the WiiU web browser doesn't have the right trust store for that. Or if you need S/MIME certificates for your corporate email system for some reason, Let's Encrypt don't offer that. If you need a special relationship with your issuer under contract (like Facebook has) then Let's Encrypt can't help you. And so on. For most people it doesn't matter.
If you use a paid CA, someone trying to impersonate you could still go to lets-encrypt and get a certificate there. In other words, the system is only ever as secure as its weakest link. It doesn't matter what link you chose, it matters what link a potential attacker would use.
All of this is because failure of a CA only means false certificates are issued. Its not like lets encrypt ever could get access to any of your private key material.