Thanks for all the feedback and compliments, people!
And sorry for being off the radar just when this article was published.
@gabriel: I see that John already replied to your question. Thanks, John!
@jghohengarten: Good suggestion, that unfortunately didn't cross my mind when writing. Not sure if I would have if I had thought about it, because the target was to write a short (well, by my standards) article. I am happy to see that Rich replied with a script to find untrusted constraints. He addresses the sys.foreign_keys view, if you change it to look at the sys.check_constraints view you will find untrusted CHECK constraints as well.
Be careful with the code Rich posted to force a check on every constraint in the database. It will do exactly what it says on the cover. If you have a multi-GB table with lots of constraints and a few of them are untrusted, then running Rich's script will force a full check of ALL constraints, not just the untrusted ones. Probably a huge overkill that will consume huge amounts of resources.
@rich: I like your suggestion to put a line break between CHECK and CHECK. Let's try if I can retrain my muscle memory to do it like that going forward.
@AZJim: You are right that locks are taken when checking referential integrity, and this can cause issues. However, I rather deal with those issues than with the issues caused by constraint violations. The constraint check is done using a pure read, so the lock will be an S (shared) lock, and released immediately after checking (even when you have set the transaction isolation level to be higher than the default), so it should not pose a big issue in most databases.
I actually dislike cascading deletes and cascading updates. They can wreack havoc in a database if improperly used. But even more important, they do not allow control over the order in which exclusive locks are taken, which means taht it can become very hard to avoid deadlocks.
To everyone else: Thanks much for the kind words!