The quote from your first quote is (emphasis mine),

> The solution. The only solution. Is to **eliminate SQL from the system** entirely. If there is no SQL engine, then there can be no SQLi attacks.
>
> What would replace SQL? An API of course! And NOT an API that uses a textual language. Instead, an API that uses an appropriate set of data structures and function calls to access the necessary data.

The rant is against letting application programmers use SQL.

The suggested fix is to let them use an API instead: which isn't SQL and doesn't allow injection.

IMO, examples of such APIs might include:

- http://bobby-tables.com/csharp suggests C# programmers can use the ADO.NET API.

  That's not a perfect example because ADO.NET is a wide or deep (i.e. powerful or general-purpose) API, which *also* allows its users to input raw (or raw-ish) SQL.

- Some SQL developers or database administrators suggest that a database should be configured such that it only permits access via (a limited number of expertly written) [stored procedures](https://stackoverflow.com/questions/459457/what-is-a-stored-procedure), and that application developers shouldn't be allowed to write their own (dangerous) SQL queries

- Another way to "eliminate SQL from the system" is to put the database (which exposes SQL) on some *other* system, accessed via a REST API or similar.

So, IMO, the overall solution or system[s] can still use a database (especially given that a database engine implements useful ACID properties, and scales well and so on, it may be foolish to try to do without one, or to write an application-specific one).

The rant's requirements are satisfied if the database's SQL API is hidden from the application developers, behind some other API (e.g. ADO, perhaps an ORM, a Web service, or whatever).

More generally I suppose it means having an application-specific DAL (a "data access layer" or "database abstraction layer"). A DAL insulates the application from details of how and where the data is stored and/or fetched. The DAL may or may not be implemented using an SQL database.