From Martin Kleppmann's brilliant book Designing Data-Intensive Applications:
"Although RPC seems convenient at first, the approach is fundamentally flawed."
Kleppmann makes the point that function calls are predictable in the sense that they either succeed or fail, based on parameters that are in control of the caller. Requests on the other hand might fail due to the network being down, or due to a latency causing a timeout, even if the original request is correct. Worse, a request might successfully reach the remote service, but fail at providing a response to the caller. This means that successfully executing a request multiple times, but failing to notify the caller, will end up causing data duplication.
“All of these factors mean that there’s no point trying to make a remote service look too much like a local object in your programming language, because it’s a fundamentally different thing. Part of the appeal of REST is that it doesn’t try to hide the fact that it’s a network protocol (although this doesn’t seem to stop people from building RPC libraries on top of REST).”
Which is not to say that RPC doesn't have its uses, but Kleppmann sees it used primarily among services owned by the same organisation.