I would note the very premise you started off your article with, that is to use the right tool for the job. I couldn't agree more. However, as the article progresses, it seems to have jettisioned that premise by saying all SQL is bad and you have to go to a non-SQL language to be effective.

SQL is a language of choice when it comes to large aggregation of data. But remember, SQL is merely a language; the internals of the tool decide the optimization. For instance, Presto implements SQL in a highly memory intensive manner than, say, Hive. In many cases Presto makes it way faster; but when joining large number of tables, that could be counter-intuitive. But doing the same without using the native capabilities, e.g. writing a Java code to get data from 10 tables and extracting 10% of that in memory is a huge waste of resources and makes the code unmaintainable. So, using the right tool for the job is crucial; not abandoning SQL.

I wish the article drove home that advise.