Also LE actually knows this attack is possible and mitigates it by validating the challenge from multiple sources so the attacker would need to be in the middle of all the LE validators and your servers.
https://portswigger.net/daily-swig/lets-encrypt-deploys-new-...
You might have access through editing a proxy rewrite rule, for example.
In the attack above you use your own SSL provider for a cert (LE not involved) and you overwrite the cert in a sense that existed before. You choose a provider that just validates with a file location. It's an attack which already requires compromise.
It’s not hard to monitor cert transparency logs, which will show this new cert.
I think it’s more likely you are not considering the full picture of the TLS ecosystem, or are making arbitrary distinctions like “cert transparency logging isn’t actually part of HTTPS.”
Consider that Symantec basically did what you suggest (mis-issue a cert) and not only was it detected and mitigated, they lost their CA business entirely over it.
You are leaving out a huge caveat here - exactly where the MITM is taking place matters a lot. In 99% cases this isn't possible unless the victim server network is effectively compromised.
The correct mental model is that it’s good enough to convince 1990’s US internet users to type their credit card into a web page. (Where the downside of a breach is that you have to dispute some charges and change your CC#.)
If you need stronger security than that, then many, many caveats start to apply.
For instance, by default, anyone that can reliably man-in-the-middle port 80 on your website can get an acme certificate for your domain from a reputable certificate authority.