Yep. PDO still leaves room for string concatenation issues. Unfortunately, so does Doctrine.
Over the years, we built one in-house at http://qbix.com/platform/guide/database because we couldn't find one. It does things like sharding out of the box, because it's able to understand the query's criteria and target it to the right shards.
As an interesting side note: Laravel's AR ORM (=Eloquent) is built on top of the Query Builder so you can leverage Query Builder with AR if you know what you're doing. Can also lead to big problems if you don't realize the possibilities and the caveats.
Chicken and egg.
Education is the security strategy that pays forward the most.
There's no technical reason the language couldn't make it so that string literals can be identified at runtime.
There are several good ways to put a stop to SQL injection. Better education is one, better APIs is another. There is no reason to just give up on the idea of using SQL queries directly because of injection attacks.
...
The answer is: Data being treated as an instruction.
Solution: Separate them so that data can never be interpreted as an instruction!
In SQLi, this solution is to use parameterized queries. You send the query in one packet, then the parameters in a second one. SQLi is thus prevented.
(Not that SQLi is the only vulnerability possible.)
So, yes, total agreement there. Parameterized queries are key. I find it crazy that anything else ever existed, let alone still gets used.
Most people don't realize how much these vulnerabilities have in common, in the abstract, until you frame it like that.