I'm not sure if this is what you mean, but I think a big thing missing from the article is how you should isolate you business logic.

A great software design will separate all business logic into its own layer. That might be a distinct project, module, or namespace, depending on what your language supports. Keep business logic out of SQL and out of web server code (controllers, web helpers, middleware, etc.).

Then you're treating SQL as the data store it is designed to be. When you embed application logic in SQL, you're hiding core functionality in a place where most developers won't expect to find it. This approach also creates tight coupling between your application and your database provider, making it hard to switch as needs change/the application grows.

That also depends on what you would consider "business logic in the database".

What would you say about CHECK constraints, though? I don't think it's something few developers expect to see, and having these checks is very convenient.

I know that there are even opponents of foreign keys (which makes sense sometimes), but in general, I don't understand why I would ever throw away the nice features of Postgres that can enforce correctness.

Pretty much yeah. I think you need to stay somewhat vigilant because it can creep in under the guise of validating data.

Triggers is something I was thinking about that is grossly misused.