Auch bei Returnwerten ist das eher unkritisch da sie auf dem Stack angelegt und nach der Zuweisung wieder verworfen werden.
Sicherlich muss ein "Return Wert" das Ergebnis auf dem Stack ablegen.
Da lokale Variablen im automatischen Speicher liegen muss dieser Wert ja "gerettet werden" um nach oben weitergegeben und wieder zerstört zu werden.
In obigem Bespiel ist der Effekt eigentlich egal, da in beiden Fällen identischer Platz verbraten wird.
Ein "Return Var1 + Var2" legt ein Zwischenergebnis an, das dann durch den Return wieder kopiert werden muss. Das Zwischenergebnis kann man natürlich auch selber anlegen und der Return kopiert dieses dann wieder.

Sehr große Zwischenergebnisse bewegen auch tatsächlich viele Bytes und zwar unabhängig davon, ob bei Varlen-Feldern alles gebraucht wird oder nicht.
Der Type Varlen (egal ob SQL oder RPG) wird nur durch Laufzeitroutinen und nicht native durch MI unterstützt.
Das Feld wird nämlich immer bis am Ende mit Leerzeichen aufgefüllt!
Dies kann man sehr schön im Debugger sehen (X-Ausgabe) oder in COBOL.
Nach der Zuweisung eines kurzen Wertes in die Variable, die vorher länger gefüllt war wird der Rest des Feldes tatsächlich initialisiert!
In COBOL wird tatsächlich eine Struktur mit der Länge (4-Byte COMP-4) und dem Inhalt definiert. COBOL unterstützt den Typ nicht native, man muss das Feld füllen und die Länge anschließend selber ausrechnen. Genau dies macht die Runtime von SQL und RPGLE.
CHAR-Felder sind also auch schneller als VARCHAR-Felder.

Man sollte sich also schon überlegen, ob Routinen dieser Art vielleicht besser die Ergebnisfelder exportieren und somit statisch anlegen. Jeder Caller ist für die schnelle Entsorgung des Ergebnis sowieso verantwortlich und Returnwerte mit 16MB sollten sowieso vermieden werden.