I feel like this is rather shallow, and, by focusing so heavily on just the transport protocol, misses a lot of more important details.
For starters, REST and "JSON over HTTP/1.1" are not necessarily synonyms. This description conflates them, when really there are three distinct ways to use JSON over HTTP/1.1: Actual REST (including HATEOAS), the "openAPI style" (still resource-oriented, but without HATEOAS), and JSON-RPC. For most users, the relative merits of these three considerations are going to be a much bigger deal than the question of whether or not to use JSON as the serialization format.
Similarly, for gRPC, you have a few questions: Do you want to do a resource-oriented API that can easily be reverse proxied into a JSON-over-HTTP1.1 API? If so then you gain the ability to access it from Web clients, but may have to limit your use of some of gRPC's most distinctive features. How much do you want to lean toward resource-orientation compared to RPC? gRPC has good support for mixing and matching the two, and making an intentional decision about how you do or do not want to mix them is again probably a much bigger deal in the long run than the simple fact of using protocol buffers over HTTP/2.
GraphQL gives clients a lot of flexibility, and that's great, but it also puts a lot of responsibility on the server. With GraphQL, clients get a lot of latitude to construct queries however they want, and the people constructing them won't have any knowledge about which kinds of querying patterns the server is prepared to handle efficiently. So there's a certain art to making sure you don't accidentally DOS attack yourself. Guarding against this with the other two API styles can be a bit more straightforward, because you can simply not create endpoints that translate into inefficient queries.