Again, gRPC has its flaws (and I'm not a fan of HTTP2), but what are you comparing it to? For internal services REST is acceptable for extremely simple, stable and low volume APIs. For everything else it is an obvious disaster: terrible CPU/network/memory performance, you need to write more code than you would have to with gRPC and get zero type safety unless you add some json schema monstrosity on top of it at which point your performance will likely take a further nose dive. Also, good luck evolving the protocol – gRPC is carefully designed to support this. Far from doing a good job, "TFA" quotes some extremely clueless article on why protobuf sucks that was ripped to shreds when posted on HN previously.
The only compelling alternative to gRPC I am aware of is capnproto (which is derivative, but in some ways nicer), but it has far less eco system maturity and mindshare.
I would argue that while Cap'n Proto's serialization is derivative of Protobuf, the RPC protocol is wildly different from gRPC.
> but it has far less eco system maturity and mindshare.
That's certainly true.
(I'm the author of Cap'n Proto.)
Counter-anecdata: my most miserable years of my career were when dealing with bespoke build and API systems that weren't Bazel and gRPC.
Google doesn't get credit for Go, Bell Labs does.