But most HTTP APIs that are commonly described as REST still use those parts of REST-over-JSON-over-HTTP, even if they aren't truly RESTful.

One thing I like about gRPC is that gRPC services use a single URL. And it doesn't ask you to define your own application error codes instead overloading HTTP status codes, thereby making it harder to distinguish application errors from communication channel errors. Things like that. But it still tightly couples itself to other parts of HTTP, particularly HTTP 3. That makes it impossible to use in a straightforward way in a number of scenarios, which then gives birth to a whole mess of reverse proxy shenanigans that people get into in an effort to avoid having to implement multiple copies of the same API.

> But it still tightly couples itself to other parts of HTTP, particularly HTTP 3

Incorrect. In fact, gRPC's primary implementation is HTTP/2 not /3. There are alternative implementation on top of QUIC, and other folks have implemented private transport implementations on top of high performance non-Ethernet networking.

The biggest I'd seen with proxies is that they didn't/don't fully implement HTTP/2 spec, in particular "trailers" which gRPC over HTTP/2 uses to transfer status code of each call.