Let's assume it happens. At the database level you can do a ROLLBACK
or even restore the whole database in the event of a castrophe. At
the database level, I have tools that can extract the business rules,
tools that properly design a schema in 5NF normal forms, I can check
the cascade actions and make sure they are done in the same order all
the time, etc. Application programmers do not have these tools.

How do you fix all the garbage data systematically created in
thousands of application programs, present programs and all future
programs? John thought the rule was (credit_limit < 10000) and Sally
thought the rule was (credit_limit <= 10000). Maybe John was right on
Tuesday, then wrong on Wednesday. Different programming languages use
slightly different rules for rounding and other functions, so the lack
of data integrity in the RDBMS is reenforced every day.

To give a common example, the orders and the order details have no DRI
actions. One program cancels an order and leaves orphan details.
Another program assumes that the orphans are valid and restocks items
nobody wanted ("We have orders for 5000 Pink Lawn Flamingoes!").

Or Program A deletes the Orders then the details, while Program B
deletes the details first then the Orders.

The real problem in most organizations is badly dsigned RDBMS schemas
that invite errors andthe lack of a central control for data ACROSS
all of them.