I don't know it's a fair comparison. REST technically is a high level standard but rarely do corporate APIs follow it correctly. Some endpoints return binary, some json, some xml (even though rest requires json) Some endpoints return usable error objects, some don't, some return standard http error codes. It relies more on the HTTP protocol layer for "signalling" compared.

RPC is, well it's a procedure call, but remotely. It's meant to be more agnostic of the layers below it, and imo gives more freedom at the function level with a very strict message structures. I find RPC to be more pluggable and friendly for large systems with many functions. Everything is a POST method, so it safely assumes data can travel both ways.

It can (and is usually) stateless over HTTP, and should be IMO.

Both have their place, for simple services I think REST is simple and assuming they follow the rules should be find for rapid development. For more long term machine-machine interaction RPC offers so much more flexibility. It means the developer is futzing less with HTTP and more on talking to a remote function (procedure)

My favorite example of RPC options are. Lets say you have a modular service, all servers can be slightly different because they can have different plugins running. Well the client only needs to know how to talk to a single HTTP endpoint forever, with a standard format. It only has to make a single GET to the server to know what features/functions are supported by the server. With REST you'd just have to assume the service is there and make an HTTP request and let the server return a 404 at runtime.

I think it might be fair to say RPC is (or at least was) far more widely used. Windows RPC for almost everything, for internal and networked services, RPC is even part of most kernels (or was when the books I read were written.