The most difficult aspect of this is that SQL is typically called from some other language (Javascript, C++, whatever), which gets data from somewhere (a web form, a previous database query, a file) and needs to plug it into a new SQL query, which generally needs to be sent to an SQL interpreter ("SELECT $DATA1 FROM $DATA2" etc), not to an inflexible pre-made compiled SQL command.

And that obviously is susceptible to injection attacks.

Really the only general way around this would be if all of those other languages had an API to communicate with a relational backend which did not interpret SQL at all, but rather only offered things like select_statement(fieldname, tablename, ...)

Such interfaces exist, but I'm not really familiar with them, nor why they're not universally used -- except to note that it's a lot of work to create an SQL library. Look at the SQL language; it's a lot to support, particularly if you need to avoid 100 arguments passed to a function, etc. (Just saying one shouldn't leap to trivializing such projects.)