For the record, I certainly think data integrity checks in the database are good. "Auditing" in the database is probably the right thing too, but that implies bureaucratic requirements. "Logging" means the same thing, but with a different motivation. The issue with doing these in the database is that all the interesting information has to be passed into the database -- like who is performing the change, and potentially other contextual information (e.g. a transaction ID, so you can view the update as part of the atomic transaction it participates in). So, I might not put "logging" logic into the database, because logging doesn't have to be enforced the same way auditing does. (For instance, in my database-related logs I usually like to give an indication of what the larger action was -- e.g., moving something vs. creating something, even if both operations result in an insert).
In a lot of my experience I find there are parts of the system that live in the database, and parts that don't. Well, that's why the database isn't an application server -- though not everyone agrees, hence many of Oracle's efforts to make Oracle an app server, and the recent experiment someone did embedding Zope in PostgreSQL. If it's only transient UI logic that lives outside of the database this seems innocuous, but when you start doing network calls, writing files to disk, and so on, the "center" starts to move out of the database and into your code, and the database seems like one of many appendages of your code. This is when logic in the database feels like a burden, and where it also feels incomplete, since the database's perspective seems much more limited than my application's perspective (unless, I suppose, you use lots of stored procedures).