Dann hast du mich falsch verstanden.
Das Absetzen eines SQL's per ODBC dauert tatsächlich nur Millisekunden.
Was die SQL-Ausführung dann leisten muss ist ein eigenes Thema.
Der Traffic beim Empfang von Resultsets hängt nun mal immer von der Menge der Daten ab.

Komplexere SQL's in Prozeduren zu verlegen macht eben Sinn, wenn man die Logik einer Anwendung eben in die SQL-Schicht verlegt (Stichwort BusinessLogik, ThreeTier-Application).

PHP kann natürlich SQL-Prozeduren aufrufen, das wird ja schon gemacht.
Allerdings muss man die Implementierung von MySQL mit Zugriff auf die DB/400 betrachten.

Prozeduren und Funktionen lassen sich ja per CREATE PROCEDURE/FUNCTION in SQL-Syntax jederzeit erstellen und sind dann auch aufrufbar.
Das hat nichts mit PHP zu tun sondern gehört eben zu SQL. Dabei ist das unerheblich ob ich das per embedded SQL, STRSQL, REXX, ODBC oder sonstigen SQL-Interfaces mache.

Man kommuniziert mit MySQL und nicht mehr mit der DB/400. Allerdings speichert MySQL seine Daten in der DB/400, so dass ein gemeinsamer Zugriff zwischen MySQL und AS/400-Programmen möglich wird.

Also das Erstellen von Tabellen und Views sowie das Ausführen von SQL's (Select/Insert/Update/Delete) werden per SQL an die DB/400 weitergegeben.

Das Aufrufen von Prozeduren und Funktionen erfolgt aber in der MySQL und werden nicht an die DB/400 weitergegeben, was durchaus Sinn macht, da man ja mit MySQL arbeiten will.

Die oben genannten Performanceprobleme sind damit also nicht lösbar.
Man muss also untersuchen, was die Prozeduren denn so lange treiben bis sie zu einem Ergebnis kommen.