To address all of your questions:
One of the biggest selling points of gRPC (or many of the protobuf based systems, like Twirp) is that there's a huge community of people building code-gen tools for the API and Client out of a .proto file. What this means is that you can auto-generate a typescript library in one command, then publish that to npm.
There's an implicit guarantee that, if the TS client library and, say, the Go backend, are both "the same version" of the API (meaning, generated from the same .proto file), you'll get full API compatibility. And its not just "the frontend is assuming the response is of type T" or "doing schema validation on the response once you get it to make sure it conforms to a type the frontend defines independently"; the client lib and the backend lib are both generated from the same source of truth.
This exists with something like OpenAPI, but Protobuf is much simpler. And then you layer something like gRPC on top of that to get all the HTTP2 benefits, and its obvious why its gaining popularity.
That being said, to the third question: There's a huge advantage in those auto-generated client libraries. That's literally how libraries like the Google Cloud SDK are made; autogenerated from protobufs. But, if you use gRPC, the state of using that on the frontend natively sucks. So its got pros and cons.
Personally, we've opted to use Twirp instead of gRPC for the time being. Its all the advantages of protobufs, but it creates an API that is easily callable by web clients because its just a simple HTTP endpoint with a JSON payload. The only big thing you lose is the HTTP2 streaming, which might come one day.