You assume you will deal with mistakes later and that will be more costly than the effort implement foreign keys. That's a pretty big assumption that has been proven to be false in many cases.

Implementing foreign key constraints requires next to no effort -- a single declaration in SQL. You need to think through the schema and the relationships but you have to do that in any case.

"Proven to be false in many cases" with not a single example is just an opinion without evidence. The benefit of foreign keys has decades of actual documentation.

I'm going to assume you didn't read the linked thread because right there are examples of both.

Assume what you want. Since I specifically mentioned migrations as a not so good reason to avoid foreign keys, in my opinion, I would think it's obvious I read the original article.

Sanely created schema does not have these kinds of problems ;). Plus FKs are a performance impact.

The most trivial schema with a parent-child relationship either has foreign key constraints or update anomalies. There's no way to "sanely create" a normalized schema that doesn't have such relationships.

Performance impact may or may not matter. You don't discard valuable techniques and decades of experience for a "might happen." You measure and identify actual performance and adjust with facts. All indexes have both a performance benefit and a performance cost, incurred in the first case when selecting, and in the second case when updating. The performance benefit and cost of foreign keys comes from the index created. You get protection from update anomalies almost for free.

Everyone comes from a different backround and experience. You are wearing a hard hat, but if you don't have the resources, then you need to be smart and not just belch up the dogmas/theoretical stuff.