Nun, SQL (Structured Query Language) ist also im Wesentlichen eine Abfragesprache, was sie eben sehr effektiv auch kann.
Insert/Update/Delete hat sich da nicht wesentlich geändert, denn die Where-Klausel ist ja wieder ein Query.
Die Prozedursprache von SQL ist sehr dialektlastig, also DB-spezifisch, und reicht im entferntesten nicht an die Möglichkeiten einer Programmiersprache. Beim SQL-Server wird z.B. davon abgeraten größere Prozeduren zu schreiben, da diese die DB insgesamt belasten.
Bei der DB2 for i ist das auch nicht viel anders. Da werden C-Programme erzeugt, die von SQL-Engine aufgerufen wird.
Da ist es doch sinnvoller, das Programm direkt selber zu schreiben und statt SQL eben Prozedur-Aufrufe zu tätigen. Das ist wartbarer und zudem noch effektiver.
Die Implementation von "pSQL" ist sehr verschieden und die wenigsten machen da tatsächlich ausführbaren Code sonderen i.W. interpretierenden Code, also eine Zwischenschicht.
Dazu kommt dann, dass bei zu langer Ausführungszeit, die von verschiedenen Faktoren abhängt, schon Mal ein SQL-Timeout gemeldet wird. Bei einem Service-Programm ist mir das noch nie passiert.

Prozeduraufrufe aus dem Programm sind mit Einzelfeldern und Strukturen möglich und daher sehr effektiv. Strukturen werden gar nicht unterstützt und Arrays sind eigentlich eine Katastrophe.

Und da ja nun MongoDB bereits angesprochen wurde, dann lest dies hier mal:

https://www.mongodb.com/resources/pr...red-procedures

Zusammengefasst: Stored Procedure wird nicht unterstützt und Stored Functions nicht mehr empfohlen. Die wesentliche und nachvollziehbare Begründung ist, dass der Optimizer da keine Chance hat, Abfragen zu optimieren.