The article does have a strong whiff of premature opt. However, using a SQL db in the first place is usually causes extra work to use something unhelpful. Usually it's way less code to just skip it.
A non-SQL solution surely can work well and be a fine solution to some problems. Especially problems that are very well understood (like problems at the optimization stage of the project).
But can a minimal non-SQL solution provide the basic features that people want and expect from a persistent storage layer: transactions, allowing multiple process concurrent access to the data, relatively foolproof failure recovery procedures, etc?
A decent RDBMS gives you those features out of the box in addition to allowing you great data manipulation flexibility. It is this sweet spot of data manipulation flexibility and fault tolerance that makes SQL/RDBMS such a ubiquitous tool.
I suspect code you're "skipping" is the code that would give you those extra features that help with reliability and fault tolerance.
While it is possible to implement those features without using the RDBMS-crutch it takes real code and real engineering effort to do it. If you are writing "way less code" you are likely not providing replacement features.
