Did you not finish the rest of the post? Yes, it's true that compressed json is not materially different in size vs protobufs. But when it comes to the speed of serializing and deserializing protobufs there is a huge gain across languages. So if you're using gRPC in backend environments you'll gain huge speed benefits.

I spoke to some of the gRPC folks at KubeCon/CNCon and the word is that browser support is in the works. There are some existing, slightly hackish ways to do it already but I'm confident that they will get it done properly.

It will be huge when that's a reality and we start building all of our APIs around protobuf.

When compressed sizes can still matter as the payload size increases.

REST is the language the rest of the web speaks so if providing a consumer service that isn't latency sensitive you should feel at liberty to give a RESTful API.

If you're building internal services, consumed internally, gRPC is a decent way to go.

If say you're providing a logging service to a number of large customers you might want to provide a gRPC service for the performance characteristics.

gRPC also provides you the option to write all your services internally using gRPC and then you can expose a JSON service without having to write it yourself.