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.
IMO the fix is to let them use an API instead, which isn't SQL and doesn't allow injection.
For example:
- 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 suggest that a database should only be accessed via stored procedures (written by savvy SQL developers), and that application developers shouldn't be allowed to write their own SQL queries
Another way to "eliminate SQL from the system" is to put it 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).