Cascading delete was on everywhere. So when the bad state went away then so did the customers, and their orders, and their payments, and ... A very bad day indeed.
Oh dear! This is why I've never implemented cascading deletes, ever. Being a programmer, I know too well how users can do things you don't expect, and so I want to be able to prevent / double-check their actions in code.
In fact I don't even like cascading updates, because you can connect to a database in lots of ways, not just through the application you *assume* people will use to update the database. A new IT contractor, or anyone who (perhaps accidentally) has the db login, can inadvertently, or on purpose, delete something that sets off cascade operations - no thanks!
Call me paranoid, but I prefer my constraints to *constrain*, not enable. 🙂 If someone wants to delete a contact record, they better be prepared to spend a few hours *manually* deleting all those transactions, invoices, etc. first. Seriously, cascaded anything is questionable - why on Earth would we make it easier for someone to mess with a db?
As for the cascading update shown in the article... In most cases, those top-level lookup tables are set up like that for a *reason* - usually tied to real-world business rules and usually are not going to change very often. So why add a mechanism allowing them to change easily on a whim? The lack of cascading updates *protects* the data in those lookup tables. If one needs to change, it's done through the application layer, which can implement any number of checks to ensure it's being done by the right person, at the right time, for the right reasons. High-impact changes, whether updates or deletes, shouldn't be made easy to do.