Sure, http-01 as defined originally has a flag for whether to do the validation with plaintext HTTP on port 80 (as today) or using HTTPS on port 443.

Now, suppose http://no-ssl.customer1.example/ is a site Customer 1 is running on a bulk host, and it doesn't have SSL. We (the attacker) ask Let's Encrypt for an HTTPS version of the http-01 validation for this name no-ssl.customer1.example

A DNS lookup of no-ssl.customer1.example gives Let's Encrypt the IP address of the bulk hosting server. They connect to port 443 of that address, and they do SNI and say they expect to talk to no-ssl.customer1.example, then they do an HTTP request with Host: no-ssl.customer1.example and a GET for the relevant .well-known/acme-challenge/ file - what happens?

A common default configuration of web servers used by bulk hosters says if anything doesn't match, let's use a "default" such as the first (often alphabetically first) named virtual host to serve the answers. No error, just assume that must be what the request was really for.

Since there is no SSL version of no-ssl.customer1.example, the server drops through to this default, and the web server offers the certificate and content for aaaaa.attacker.example which we, the attacker have prepared. This includes the ACME answer file, Let's Encrypt is satisfied we have "control" over no-ssl.customer1.example and grants us a certificate we clearly shouldn't have.

Apache and nginx both do this by default. Lots of bulk hosts are set up to use them without a configuration that prevents this happening, and they didn't seem to be in any hurry to fix it.

So, Let's Encrypt disabled this feature for their production release.