It's obvious to me and I imagine most programmers, too.

However, as a data engineer I've been at some companies that treat SQL differently and seen bad practices that I believe the article is addressing, like putting SQL statements as stored procedures or materialized views instead of in git.

From the outside looking in, and when framed this way, it's obvious. But when SQL at a company is entered into a semi-bespoke internal system fronted by a textentry box on a webform, and there's no editor or git anywhere to be seen, it's less obvious that the work required to get it into a version control system like the rest of the code is even possible, never mind worth it. Especially when the data science team has a primarily statistics background and less of a programmer one. (even then, a programmer background doesn't imply a person knows git/version control.)

I think the gap is that most startup types don't use stored procedures, so their SQL is committed to version control by default. Few places do migrations to update their database in any way including the stored procedures that also works well. Nothing new, except for those not already doing one of these things.

"Because it is code?"

It’s obvious to most programmers - this was common practice in the previous century - but there’s been a spike of data scientist/analyst jobs where that might not be as common, and there used to be more of a subset of DBAs who self-identified as not being programmers and avoided “hard” things like this. I’ve definitely had people in roles like marketing have to deal with confusion or bugs caused by reports changing in undocumented ways.

Yes, it was that bad of an article.

It's the second one.