Zu den Nachteilen der RPC-Technik zählt der Umstand, dass es keinen einheitlichen Standard für RPC-Calls gibt. Die unterschiedlichen – meist firmenspezifischen – Umsetzungen (z. B. ONC-RPC von Sun) sind untereinander normalerweise nicht kompatibel. Zudem bringen die Transfer- und Übermittlungsebenen RPC-basierter Systeme gewisse Geschwindigkeitseinbußen mit sich, was bei rein lokalen Prozeduraufrufen nicht der Fall ist. Da Client und Server für ihre jeweiligen Routinen unterschiedliche Ausführungsumgebungen nutzen, wird auch die Verwendung von Ressourcen (z. B. Dateien) aufwendiger. RPC-Systeme sind daher für die Übergabe großer Datenmengen nicht so gut geeignet.
Durch die Aufteilung auf verschiedene Verarbeitungsinstanzen wird die Fehleranfälligkeit erhöht. Nachrichten können in der Kommunikation verlorengehen (Netzwerkfehler, Ausfall eines Knotens im Netzwerk), es kann zu Verzögerungen und Abbrüchen kommen. Timing-Probleme, redundante Doppelausführungen (z. B. von Prozessaufrufen) oder unerwünschte Asynchronitäten in der Maschinenkommunikation zählen zu den daraus resultierenden Komplikationen. Beim synchronen RPC kann ein Serverproblem (z. B. Crash) den Client beeinträchtigen, wenn der aufrufende Prozess vergeblich auf den Rückgabewert wartet. Andererseits wird der Server ausgebremst, wenn die Antwort des Clients zeitverzögert bzw. gar nicht bei ihm ankommt. Diese Fehleranfälligkeit kann sich gerade in umfangreichen und hochgradig arbeitsteiligen Architekturen weitreichend auswirken.
Aufgrund möglicher Fehlerquellen muss außerdem eine spezielle RPC-Fehlersemantik berücksichtigt werden, was die Programmierung verhältnismäßig aufwendig macht. Programmierer und Systementwickler müssen sich mit den Sicherheitsaspekten auseinandersetzen, die verteilte Systeme und ihre Kommunikation via RPC und UDP/IP bzw. TCP/IP mit sich bringen (Netzwerksicherheit, Hacking, Denial-of-Service-Angriffe usw.).