Many of the arguments there boil down to:
"SRV points to host names instead of IP address, so this is 2x the DNS round-trips compared to A records."Basically, they're complaining about the added indirection slowing down the user experience.
Analysing their arguments is interesting.
First: In 20 years since this rejection by the Mozilla and later the Google teams the load-balancing problems have been solved... just as inefficiently. The typical implementation of global services load-balancing (GSLB) or global traffic management (GTM) as commonly used in Citrix NetScaler or BIGIP F5 is to use DNS CNAME records pointing at a DNS stub zone "owned" by the load balancers. This delegation is done via NS records that have to be looked up as a second step. The appliances then return either a CNAME or A record pointing to the actual web servers. So between 1-4 DNS lookups is typical, but I've seen as many as 10+ in extreme cases. Azure CDN comes to mind, which has 6 CNAMEs in a row across several domains and associated name servers.
More importantly, caching typically doesn't help much with GSLB/GTM, because they inherently must use short TTLs. There's a very direct trade-off between availability and performance. Typical TTL times are single-digit seconds to a couple of minutes at most. If it were any longer, clients would continue to try to connect to failed sites for a long time before giving up and requesting a fresh DNS address from the load balancers again. Hence, because of these low TTLs it is common for every page view on such sites to trigger at least one DNS request if you're clicking around at a normal rate. Hilariously, this doesn't show up in benchmarks because load-testing tools load pages fast enough to amortize this cost, so developer and testers don't notice!
Second: Modern DNS servers use the "additional" section in their responses to also include the "A" records along with the CNAME or SRV host names. Windows Server DNS does this by default, as do many others. This means that the additional round trips are zero as long as the SRV records point to a zone managed by the same name server. In other words, SRV-based load balancing could use a single round-trip just like efficiently implemented GSLB/GTM solutions.
This then combines with the client-side failover capability of SRV records to allow long TTLs, on the order of hours or days. Clients aren't forced to flush their DNS record caches to connect to secondary or tertiary sites, as they already have the records available and can fail over faster than with GSLB/GTM.
Third: The "workaround" for the inherently poor DNS performance of traditional GSLB/GTM is to use IP routing tricks that make a single IP route to the nearest data centre location instead of a single destination.
Cloudflare's 1.1.1.1 service and Google's 8.8.8.8 work like this, as does Azure Front Door. However, this is something that inherently requires a large scale to implement and is typically unavailable to small organisations. More centralisation of power into the hands of a few megacorporations is not healthy for the Internet!
As an aside: I've noticed that Azure DNS Zones does not use the "additional" DNS response section, which means that two sets of lookups are required for every CNAME or SRV query. This doubles their revenue for alias records of all types compared to the more efficient implementation. I wouldn't say that this was done in bad faith, but from the outside it certainly looks... suspicious. Certainly, their incentive to grow their cloud revenue is much more direct than some nebulous public good of a "better, faster web".