I don't think this changed what you think it changed

Historically a Certificate Authority did whatever it pleased to validate control over the name. It is _definitely_ true that an adversary who "was on your gear" could get a certificate.

Once the CA/B Forum comes into existence (which is when those green bar "EV" certificates appear) there are rules for how to do this validation, but, crucially, those rules have a clause which says "Any other method". Yup, CAs were still free to do whatever they wanted.

By 2010 or so they could get a "free trial" certificate, which would be annoying for a real site owner but crooks don't care about that, the "free trial" period is long enough to get the job done, and if the site's actual owners get billed for exceeding their "free trial" well boo hoo.

In 2016 the CA/B voted on new rules for validation which got rid of "Any other method" but although the vote passed, it was tied up in lawyer hell because it turns out commercial CAs owned patents on lots of crappy methods.

In summer 2017 Mozilla got tired of the foot-dragging caused by lawyers and simply changed _their_ trust rules, which in effect unilaterally changes the rules for a public CA since "Our certificates don't work in Firefox" might as well say "We don't want to be in business any more, bye".

These new rules are the Ten Blessed Methods (but now only eight or nine are in use) but crucially Let's Encrypt, unlike a lot of commercial CAs, had been compliant from its creation, indeed its staff helped write them.

Your rosy view is totally wrong, here are two REAL examples of things actual publicly trusted CAs were doing prior to the Ten Blessed Methods which weren't even _prohibited_ even though they're worthless:

1. Send an email to administrator@example.com with a link in it. If the link is resolved, this validates that the legitimate owner of example.com wanted a certificate issued for any name under example.com

What if an "anti-virus" gateway dereferences the link to check if it's a viral payload before trying to even deliver the email?

"Hi, An Actual Criminal wants a certificate issued for login.yourbank.example. As the Administrator please click this link to authorise this certificate."

[ AV software dereferences link. Cert issued to An Actual Criminal. The system works... ]

"I'm sorry, administrator@yourbank.example doesn't exist"

[ Oh right, nobody at yourbank.example actually even saw the verification message. Well I'm sure it's fine ]

2. Tell the applicant to specify a URL where they can see a special one-time code, once the applicant confirms that's done check the one-time code is seen at that URL

What if the attacker suggests a URL that is just the one-time code, URL escaped, and the result is a 404 error reciting the code because that's just how your server's 404 errors work?

Nobody would accept a 404 error as proof? Right? Wrong. Well, OK, but once they fixed that it's fine, right? Wrong, lots of commercial HTTP servers don't send 404, they send a redirect and paste your message into the redirect, thus passing the test.

Let's Encrypt's design actually does a pretty good job here, if you feel this isn't enough then the reality is that before the Ten Blessed Methods many other trusted CAs were _worse_