Most software doesn't really need fixed port numbers. A few older systems like the DNS system are in practice limited to a fixed port, but most newer systems are port-agnostic. My postgres server is conflicting with some other service using port 5432? Who cares, I will just start it on some other random port. All that changes is that I have to type 5 more characters when connecting to it. SRV records are quite nice for user facing addresses because it's less stuff to remember, but for the majority of protocols it's not needed.
Until people start to offer tens of thousands of services per IP, we won't hit any port shortage. And in the hypothetical future where that happens we hopefully moved to IPv6 and can just use another IP address.
Two points; firstly, SRV records offer other advantages over A records beyond simply port diversity.
Most notably: the ability to exist at the apex of a domain, resolving to both IPv4 and IPv6 addresses simultaneously, and weighted-round-robin and fallback support.
The overload of the address record to discover service endpoints is ultimately a murky throwback to when servers were named like pets, not disposable commodities.
Secondly, in this age of containerized deployment it is already common to have many HTTP-substrate services bound to a single address, disambiguated by port. Leveraging the SRV record in DNS means not having to invent yet another endpoint discovery mechanism just to know what port number to connect to.
The reference to "typing an extra 5 characters" invokes a world of manual, static configuration that many of us are happy to have replaced with services that find each other through discovery protocols.
Until people start to offer tens of thousands of services per IP, we won't hit any port shortage. And in the hypothetical future where that happens we hopefully moved to IPv6 and can just use another IP address.