Hi @boyandin,
It's easy to see how this could be significantly more convenient for users, and companies like Apple have also proposed this idea in this past.
I think the main reason for this limitation is an issue called protocol-in-protocol or protocol-confusion attacks. Researchers have demonstrated a number of ways that software can be tricked into doing the wrong thing if it has a different assumption than the other end of the connection about what Internet protocol will be used between the two.
A secondary but also very important reason for the limitation is shared hosting in general. In a shared hosting environment, there might be many customers on the same IP address. If we allow domain validation for these services, we need to be sure that the hosting provider understands the implications of allowing a particular user to run or administer a particular service. A sensible conclusion is that hosting providers don't assume that letting user A run a certain service on a specific privileged port would automatically allow user A to issue certificates for user B's domain.
Similarly, if a hosting provider allows all its users to post content via some comparatively obscure service running on a privileged port, it would be hard for the hosting provider to confirm whether or not this specific ability could be used to validate domain control to a CA via the ACME protocol. The hosting provider might not even be familiar with what it needs to check when setting up some new kind of TCP service.
These issues can be very serious in shared hosting because of issues like virtual host confusion (miTLS, Triple Handshake, SMACK, FREAK, Logjam, and SLOTH), and similar considerations led Let's Encrypt first to discontinue the original plan for the proposed HTTPS-01 validation method (which would have worked the same as HTTP-01 except over HTTPS on port 443) and later to deprecate TLS-SNI-01, because a researcher found a plausible way that one shared hosting customer might be able to complete the validation on behalf of another customer on the same shared hosting server (mentioned at What you need to know about TLS-SNI validation issues).
The research that led to these conclusions was relatively subtle and based on considering what assumptions shared hosting providers do or don't make when setting up web services. Unfortunately, if arbitrary ports were allowed, security researchers would have to consider what assumptions shared hosting providers do or don't make when setting up every service that the providers' customers can potentially affect content in.
There might be ways of solving this for specific ports and protocols, but they would require new technical research and adoption by the CA/Browser Forum, which sets the rules for domain-validated certificates. In their current rules (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf), you can see the following:
Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 (smtp), 22 (ssh).
These are the only port numbers that they currently permit CAs to use for DV proofs of control. Let's Encrypt doesn't support the use of port 25 or 22, but I'm sure you can see that using these ports would also commonly result in service-outage issues.
It's true that the Unix world has a strong traditional rule that control of a privileged port indicates approval by the system administrator of the associated activity and that this rule is still important today for a number of security properties. But for certificate issuance, it's very tricky to define clearly exactly what "control" and "associated activity" mean, and how we can be sure that the CA and system administrator will share the same interpretation in practice. This is especially true when the domain validation method is newly invented and has no prior history of use, so we can't assume that any sysadmins have ever heard that this specific method will be used in the future to verify their approval of certificate requests.