Yeah. Easy things are easy with most technologies... It's only after a while that you start to see the 'problems'.
With grpc... It's designed by Google for Google's use case. How they do things and the design trade-offs they made are quite specific, and may not make sense for you.
There are no generated language interfaces, so you cannot mock the methods. (Except by mocking abstract classes, and nobody sane does that, right)
That's because grpc allows you to implement whatever methods you like of a service interface, and require any fields you like - all are optional, but not really, right.
Things that you might expect to be invalid, are valid. A zero byte array deserialised as a protobuf message is a perfectly valid message. All the strings are "" (not null), the bools false, and the ints 0.
Load balancing is done by maintaining multiple connections to all upstreams.
The messages dont work very well with ALB/ELB.
The tooling for web clients was terrible ( I understand this may have changed )
The grpc generated classes are a load of slowly compiling not very nice code.
Like I say, if your tech and business is like Google's ( it probably isn't) then it's a shoe-in, else it's definitely worth asking if there is a match for your needs.
Also: why wouldn't grpc work well with load balancers? It's based on HTTP/2. It's well supported by envoy, which is fast-becoming the de facto standard proxy for service meshes.