How would it allow named virtual hosts? The only thing you have at the network layer is the IP address that the message was sent to, that's why HTTPS virtual hosts is difficult to implement.
When a client makes an initial HTTPS request, there is a high likelihood that they want to submit confidential information. Therefore the browser and server perform an SSL handshake so that the initial client's first GET/POST/WHATEVER is encrypted.
Virtual hosting requires looking at the client-supplied host header value in that GET/POST. In order to return the right SSL certificate we need that host header value to determine which site's cert to serve. But we can't get at that host header value until the SSL negotiation has completed. So virtual hosting for HTTPS on a single IP is simply not possible at present due to this catch-22.
With the idea of SRV records for port values, virtual hosting for HTTPS becomes possible. I simply map each new site's certificate to a new port number. When the client makes a connection, we already know in advance what certificate they are looking for because only one is bound to each specific port.
Under the current schema, we need a discrete IP address per SSL certificate in order to avoid this problem, but with SRV's, we can use a port number to hold the same mapping, without requiring the client to put in :port (which would work today for virtual HTTPS hosting if we could get everyone in the world to somehow know in advance what port number they want).
I suppose a variant of this is possible today. Imagine I have a storefront at foo.com. A client enters store and puts stuff in their cart. They never enter my store by typing HTTPS in their browser. My site could hardcode the link to https://www.foo.com:444/ inside the "Checkout" link, and I could have many other SSL hosts all sharing the same IP in that manner. I can understand why web hosts and their clients wouldn't really like this idea. But the SRV method would be elegant enough to be adopted, IMHO.