Bob Martin is clearly exaggerating to make his point more clear. But what is his point?

> Does he just want people to stop using SQL/Relational Databases because of SQLi attacks?

To my understanding, in that blog post (your first link) Martin tries to convince people to stop using SQL, but not relational databases. These are **two different things**. 

SQL is an extremely powerful language, and it is standardized to some degree. It allows to create complex queries and commands in a very comprehensive manner in a readable, understandable, easy to learn fashion. It does not depend on another programming language, so it is usable for most application programmers, no matter if they prefer Java, C, C++, C#, Python, Ruby, Javascript, Basic, Go, Perl, PHP, or something else.

However, **this power comes for a cost**: writing safe SQL queries/commands is harder than writing unsafe ones. A safe API should make it easy to create safe queries "by default". Potentially unsafe ones should need more mental or at least more typing effort. That is IMHO why Martin is ranting against SQL in its current form.

The problem is not new, and there are safer APIs than standard SQL to access a relational database. For example, all OR mappers I know are trying to provide such an API (though they are typically designed for other primary goals). Static SQL variants make it hard to create any dynamic queries with unsanitized input data (and that is not a new invention: Embbeded SQL, which uses often static SQL, is around 30 years old).

Unfortunately, I am not aware of any API which is as flexible, as standardized, mature, language-independent and also as powerful as SQL, especially dynamic SQL. That's why I have some doubts about Martin's suggestion of "not using SQL" as a realistic way of solving the mentioned problems. So read his article as a thought into the right direction, not as a "best practice" you can blindly follow from tomorrow on.