I am feeling like a crazy person today.
Why can you use an unsecure prep query to send off to store and forward (i.e runSFPrepUpdate), but cannot use a named query to do the same?
Prep updates can be packaged nicely by the Gateway and sent off to the (asynchronous, queue-driven) Store and Forward engine with the necessary database-specific formatting. Named queries are designed to be synchronous direct database updates with immediate success/failure reporting, not ever intended to be passed through the asynchronous engine. This is my limited understanding, hope it helps!
The named query API is different, and built around the idea of your resource context being distributed in your project.
The nice feature of runSFPrepUpdate is that everything is packaged in one function, so it's more "portable"
{My Bold}
Prep queries are not insecure. They are only insecure when used from Vision, because the Vision client supplies the base SQL. They are otherwise exactly as secure as named queries, when used with constant SQL. And NQ's have a huge remaining security hole in Vision if you allow query string parameters.
It feels insecure when putting a string into a function versus a catered named query. I suppose they are both the same at the end of the day in terms in SQL Injection will only really happen if you don't scrub/validate inputs.
Prep queries expect you to use ? substitutions to supply user input, just like NQs expect colon-delimited value parameters. NQ's actually add a layer of possible bugs for the latter (and have) because JDBC requires ? and doesn't understand the colon delimited format of NQs.
If you are using Prep queries where you are supplying values by string concatenation, you are defeating their purpose.
If you place a prep query's constant SQL, with ? placeholders, in a script library as a top-level constant, it is as "catered" as a named query.
Explained like that, it definitely makes sense. I hadn't considered the translation of the NQ to the JDBC interface.
I rescind my statement, I am now more educated.
As always, a pleasure @pturmel