I don’t believe this to be the case. Even if the connection between Certbot and the ACME CA was subject to an active MITM (or just straight up plain HTTP), the protocol is designed to be immune to replay/relay/modification attacks (in terms of mis-issuance anyway). This is thanks to the use of JWS and embedding the JWK thumbprint in the key authorizations.
You are certainly right that the obscuring of IP numbers is not a real hurdle for a determined attacker.
I believe this is more about discouraging the practice of whitelisting so that Let’s Encrypt does not end up in a situation where there are millions of deployments using whitelisting, leaving Let’s Encrypt completely unable to change their validation practices due to the massive incident it would cause.
We already know this happens on a minor scale because there have been a lot of help threads posted here when AWS was introduced into the validation server pool.
That flexibility to change their validation practices has to be protected in order to be able to deal with attacks like this and any other research that will appear in the future.
FWIW, the people who develop Certbot and the people who run Let’s Encrypt, are completely different sets of people in different organizations.
The one thing I will say in favor of something resembling your proposal is that having a list of observed addresses would make troubleshooting/helping people much easier. I wrote a program at the end of last year (
va-monitor) which is an HTTP server + dnstap sink, creates orders occasionally, and logs what addresses it sees for each validation method and ACME directory. But I hesitate to publish anything because of the risk that people will just copy-paste crap into