Agreed, but the protocol does not allow for deviation without creating a new protocol; which to your point, Google did. Google could have introduced SRV records as optional components in the spec. So the lack of mention of DNS standards in the protocol is sufficient to block the implementation of a new DNS requirement.
Browsers are not the only thing that speak http. There are a myriad of libraries used by API's and all manor of automation that must also be updated to support a new protocol. A good example of this is SNI. All major browsers support SNI, but there are plenty of libraries that have yet to catch up to that very well aged protocol.
Funny thing is, TBL anticipated this years ago when registering the service names. Read the assignment notes at https://www.iana.org/assignments/service-names-port-numbers/... - yes it's talking about DNS-SD specifically but the remark generalises to all service discovery, basically setting the expectation of different service names based on intended use.
API endpoints tend not to be apex records, indeed are characterised by using a label of "api" or similar which doesn't automatically conflict with other services, certainly not in the common case. It'd remain a violation IMO to use a host name as a service selector but in practice they could continue using address records for many years of transition.
Browsers are not the only thing that speak http. There are a myriad of libraries used by API's and all manor of automation that must also be updated to support a new protocol. A good example of this is SNI. All major browsers support SNI, but there are plenty of libraries that have yet to catch up to that very well aged protocol.