This entire topic is very, very old. It was first brought up in 2015 (back when Let's Encrypt started turning their ACME protocol into a standard), 4 years before RFC8555 came to existence and while ACME was still under active development. In fact, it's the fourth issue ever raised on ACME: Define a new challenge type that runs on a dedicated port · Issue #4 · ietf-wg-acme/acme · GitHub, although most of the discussion happened elsewhere. See [Acme] Issue: Allow ports other than 443 for reference on some of the discussions that went on back then.
Several arguments were made on both sides, both for allowing non-port 80/443 validation and forbidding it strictly. The key concept that we need to understand is what the challenge is even trying to do: An ACME HTTP-01 challenge attempts to validate if a requester controls or owns a domain name, because that's the thing that a domain-validated certificate represents: The entity obtaining the certificate owns or controls [1] the domain name.
HTTP-01 is IMHO a weak start to begin with, because the only control that it demonstrates is control over the webserver running at port 80 (or port X for a customized port). Control over the domain name is inferred by the fact that DNS resolves to the IP address at which the webserver is reachable. So we infer the relationship from there. This isn't perfect to begin with, but it's sort of accepted behaviour as HTTP challenges are quite easy to do with little hassle from the subscriber's POV.
The main argument made against allowing non-port 80/443 validation is that it weakens the relationship even further: Now we're not only inferring that the webserver at port 80/443 controls the domain name, but we also infer that some webserver running at port X (say 647 in the examples above) is controlled by the same entity that also controls port 443 - because that's where the certificate is going to be deployed, right? So the claim is made "both webservers are run by the same entity", but the ACME CA (with the current http-01 method) has no way of validating this claim - it just has to trust it. This is sort of worsened by the fact that certificates cannot bind validity to a given port number [2], so if we validate on port X the certificate is valid for any other port on the same domain. If certificates were to bind a specific port that would be much easier ("you validate on port 647, but your cert is also only valid for port 647"). But this semantic doesn't exist, it likely will never be for practical reasons.
The question is now: Is this second assumption a problem, or is it true with such a high probability that we can just ignore it? Well, the truth is we don't really know. On the mailing list a few scans were attempted to determine this. A primary concern was that shared webhosters exist which treat ports other than 80/443 differently, which could allow for takeover attacks by users sharing a webhost. CGNAT is another problematic example ("I can port forward 555, so I can get a cert for port 443 which I cannot forward").
You can of course try to fix this with authentication: Devise a new challenge type that somehow proves that the webserver at port 443 + 647 is the same entity, but that probably opens up other questions: If you need to bind the ports together anyway, what benefit is left? How does this outweigh the complexities involved?
Eventually, I think the interest did not outweigh the (possible) risks. The CA/B forum has the ultimate authority whether to allow non-standard ports for validation, and they decided to not allow it. To change this, a motion needs to be put in place, demonstrating to the members how allowing the other ports outweighs the possible risks and complexity involved. I am not saying that this cannot happen, just that this has not happened in the 11 years since we first discussed this.
[1] Source: Baseline Requirements 3.2.2.4 Validation of Domain Authorization or Control
[2] This is the source of several TLS attacks, such as the ALPACA Attack