In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header:

Otherwise, the authority component is assigned the default name configured for the server and, if the connection's incoming TCP port number differs from the default port for the target URI's scheme, then a colon (":") and the incoming port number (in decimal form) are appended to the authority component.

This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion.

The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing -semantics. And that section is a bit weaselly in that regard, using a "SHOULD...unless".

The target URI's authority information is critical for handling a request. A user agent SHOULD generate Host as the first field in the header section of a request unless it has already generated that information as an ":authority" pseudo-header field.

If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory).

Just to confuse things, the absolute-form says this, which might be read to imply that Host truly is mandatory:

A client MUST send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form

The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.