SQL is a fine place for business logic. Just be reasonable about at what level (database or application) you process things so you don’t end up with outrageously complicated queries or outrageously inefficient application behavior. The author seems to have mistaken “there is some logic which is better implemented in an application language” for “all logic is better implemented in an application language” (and then even walks it back at the end). Remember, folks, only a Sith deals in absolutes!
The place business logic shouldn’t live is on the database, e.g. in stored procedures or complicated views, but for reasons that have nothing to do with SQL the language. I’ve yet to see a good way to version or manage code that lives on the database (or schemas, for that matter, but that’s a different issue)—every option seems to be either bad, incredibly complicated, or fragile, and most are a hand-rolled solution nicely combining all three deficits.
Is the example given really an example of business logic? I’d call it presentation, and in a modern web app I would think about pushing it all the way out to the client.
SQL is still the best choice for filtering, sorting, and aggregating, which happens to include a lot of business logic.