The problem isn't so much concatenation, as it is, concatenation based on dynamic (e.g user-submitted) input. In some (admittedly rare cases), it's hard to avoid concatenation since not every part of an SQL query can be parameterized, such as table names.
(Fun "fact", I vaguely remember that, once upon a time, even things like parameters in limit/offsets weren't universally supported. Also, and correct me if I'm wrong, first class support for arrays (e.g., via any($1)) is relatively new).
It's worse...the call doesn't even support bind params. There is a "$wpdb->prepare()", but it's not real bind params, but rather a bunch of php quoting, escaping, and stripping. And in this case, they didn't even do that.
So basically, by lowering the barrier to entry and making it easy, they've actually made it difficult/impossible to write even slightly secure code whilst simulataneously encouraging the level of developer who has no idea what they are doing.
Legacy. Plus the ODBC layer is sort of 'broken' then add on nearly 25 years of examples on the internet.
We have 2 modes of using ODBC/SQL.
Almost tightly bound. Basically you have a bit of query string with question marks in it and you bind out your data points. Either for sending/receiving. Even passing in prepared strings could be an attack vector if you know what you are doing. As it breaks one of the 'rules' of secure programing trusting the client to tell you the correct thing. This however is the currently the only best way to do it, unless you go full on with the stored procedure pattern (which can still have injection attacks).
Loosely bound. Here is a totally composed string ready to go just run it. Also a good way to make easy SQL injection attacks.
Both involve string manipulation.
Then a requirement of that interface is it has to sort of kind of work with at least 4 different SQL systems. Anyone who has had to port stored procs between some of these different SQL systems, can attest to, that they are not the same, except in some very basic ways.
On top of that there are a lot of bad examples out there. But also once someone finally kind of gets something to work they may cut and paste that method. Which may or may not be good. Plus SQL has this stigma for many years of 'being hard'. I know I ended up as the 'SQL guy' for awhile because many in some of my orgs would not touch it.
That is what the runtime environments have to deal with. Some paper over it with an API abstraction, some are better than others.
