Die Perfomance ist nur bedingt vergleichbar.
Je nach Funktion, die benötigt wird, ergeben sich halt Unterschiede.
Die schnellste Variante ist sicherlich das Zurückgeben ganzer Recordsets. Dabei ist der Aufruf selbst absolut zu vernachlässigen.
Wird mit einer Prozedur nur wenig gemacht, ist der Aufruf zwar relevant, aber in den meisten Fällen nicht wirklich messbar.

Hintergrund:
Wenn ich per CLP einen CALL mache, muss erst das Objekt ermittelt werden bevor der Aufruf erfolgt.
Wenn ich per HLL-Programm (RPG/COBOL) einen CALL 'Konstante' durchführe, ermittelt das System beim Programmstart die Adresse des Objektes, so dass der nachfolgende CALL dann etwa wie ein GOTO wirkt.
Ein Aufruf CALL VARIABLE ist wiederum nur beim 1. Mal langsam (Objektsuche), bei Wiederholungen wieder wie GOTO zu verstehen.

Was den wesentlichen Zeitfaktor beim CALL angeht, so sind das die Resourcen, die bereits beim 1. Aufruf benötigt werden.
Bei ILE-/RPG alle Dateien, die automatisch geöffnet werden sowie alle CALL 'KONSTANTE', und zwar unabhängig davon, ob sie im Laufe des Programmes auch tatsächlich benötigt werden.
Deshalb ist es manchmal sinnvoll, Dateien mit USROPN zu öffnen und Programme per Variable aufzurufen (allerdings fehlen diese dann bei DSPPGMREF).
Bei RPG kommt dann noch die *INLR-Abhängigkeit hinzu, ob wiederholte Aufrufe beim nächsten mal schneller sind.
In COBOL werden Dateien immer per USROPN gesteuert, einzig die CALL's werden initialisiert.
Bei CLP's und C-Programmen gibt es keine Resourcen, ie beim CALL initialisiert werden müssen.

Der Aufruf von Serviceprogrammen soll mitunter der schnellste sein.

Aber: Diese ganze Diskussion ist fast nicht relevant.
Ich habe bereits mehrere 1000 Call's pro Sekunde in einem Batchjob gesehen, bei gleichzeitig ca. 1500 weiteren parallelen Job's.

Viel Problematischer sind da eher falsche SQL's (Zugriffspfade, Tablescan's) sowie das Netzwerk bei Remote-Zugriffen.
Was bringt mir da eine Optimierung der CALL's um Microsekunden, wenn der Netztransfer Sekunden oder der SQL Minuten benötigt.