Naturally he's not talking about choosing deliberately bad technology, so much as he's saying to lean toward choosing crude tools for most tasks, and only opting for sophisticated tools when experience shows you need them.
What I particularly like about this idea is that it short-circuits the idea of even wanting to have nice things, so that you can get straight to solving the problem in the most direct way possible. If your dinky solution doesn't work, it's probably also fairly easy to replace when the time comes.
For example, it's easy to slurp CSV files into almost any database, and code that relies on CSVs for storage probably has a simple enough interaction model that it's easy to migrate it as well. So picking CSV might make it easier to get to work, and save tomorrow's problems for tomorrow. But migrating from PostgreSQL to Cassandra, or vice versa, is a terribly daunting change. So you really want to be sure you're making the right decision on the first try. It's really easy to let that knowledge breed analysis paralysis - and it's arguably even irresponsible not to let it do so.
I have similar thoughts on programming languages: I'd rather default to the crummy old one, because newer, more sophisticated tools are much more likely to be able to easily speak to code that's written in a crummy old language, than to be able to link to each other.
The overall article isn't really about the question at hand, but some of Yossi Kreinin's thoughts here also seem pertinent: https://yosefk.com/blog/redundancy-vs-dependencies-which-is-...