Similarly, I often found that handling referential integrity for a one-app database was handled better in the app, not the DB. Why? Again, because the app knows *why* the reference failed, the DB only knows *that* it failed. And handling recovery still requires the app to know what's going on. Again, for a PHP app, it was so much easier to do it in the app and not tell the DB.
The key advantage of doing this in the DB is that the DB can enforce it. When your working on a big project this is very valuable. Over the years I've spent a lot of time finding and fixing code that is almost but not quite properly transactional. Projects that enforce RI at the DB level generate fewer such problems.
It's rather like an enforced coding standard. If the system is small enough that the programmer can keep the entire thing in mind then you don't need elaborate protocol for code safety and clarity. The bigger the project the more important it is that the project have an organized system and design.
Jay