I think it'd be more flexible, a lot less new code, and perhaps easier for the developer, just to use parameterised queries for these cases. See query_parameterised.
It was added because at some point I realised that it was bad that there was a percentage of queries our abstractions couldn't handle cleanly, forcing people to write SQL, and I know most people do not know how to write SQL securely. So it was never used, but it was put there as an important tool for developers to be able to use.
(As an aside, I interviewed someone for my bay area employer the other day, an experienced programmer and team leader - and they didn't know how to assemble native SQL to avoid SQL injections. That kind of demonstrates why parameterised queries are important.)
I can see that. Raw SQL is a very bad idea whenever user input is involved (I wouldn't even use it for the most trusted of users because an accidental unescaped character could cause chaos). And parameterised queries help do some of the escaping for you.
(As an aside, I interviewed someone for my bay area employer the other day, an experienced programmer and team leader - and they didn't know how to assemble native SQL to avoid SQL injections. That kind of demonstrates why parameterised queries are important.)