Re: SQL is the problem
A good programming language is one which allows the developer to express the requirement clearly and should be equally clear to read for anyone who has to maintain the code afterwards. For its given domain SQL does just that and it's a good deal less verbose than what I understand COBOL to be.
I'm not sure of your preferred programming language but whatever it is could you give an example of how you think it should be done to extract data joining, say four tables, with selection criteria spanning at least five columns in at least three of the tables. At least one of the criteria should be a range of values and at least one other should provide the equivalent of a SQL OR clause to filter on multiple values for that column.
Then explain how the resulting code meets the clarity of expression and reading criteria better than the equivalent SQL.
The problem in TFA is not SQL It's in constructing the SQL on the fly as opposed to parametrising a pre-written statement. About the only benefit of your "real" programming language is that parametrising would be unavoidable. The downside is that you'd have to produce a complex set of statements for each individual SQL statement you replace.
I'm trying to cast my mind back 40 years to the time before Informix adopted SQL and we had to use a C library instead. Fortunately time is shielding me from that.