While Cap'n Proto is certainly capable of replacing gRPC here, obviously Google has a lot more people working on the gRPC ecosystem, and so more infrastructure has been built out there. With Cap'n Proto you will have to do more things yourself. If your needs fit well into the model supported by common gRPC infrastructure, this may not be worth it to you. On the other hand, if you have a more unusual use case, then you might find you have to build custom solutions either way, in which case Cap'n Proto's more fundamental benefits (serialization performance and object capabilities) may make it a better choice.
Cap'n Proto is especially powerful for:
* Stateful services, where nodes across a cluster need to control and hold on to the state of other nodes. For example, Sandstorm.io (startup I founded) built a cluster-scaleable version of Sandstorm called "Blackrock" which is itself a container orchestrater designed to run many heterogeneous container instances on behalf of individual end users. This is a fundamentally stateful thing, since each container is serving a specific user with specific state and can't simply be interchanged with others. Using Cap'n Proto as the underlying communications protocol made this a lot easier to manage.
* IPC use cases, where services are running on the same machine and can communicate via unix sockets or even shared memory. Cap'n Proto's CPU performance shines here (while its somewhat higher bandwidth usage becomes irrelevant). Running multiple services on the same machine isn't really in style right now, but my current employer, Cloudflare, does a lot of it -- every one of the machines in our edge network runs an identical set of services so that any one machine can handle any kind of request on its own.
But if you're doing a standard kubernetes microservices thing... probably going with gRPC is going to be a lot easier right now.