Interesting points, however I would draw a distinction between data integrity, business rules, and UI elements (such as formatting). Experience tells me that whatever is physically allowed in the DB will get in there at some point; and we all know that "the app" isn't the only way of interfacing with the DB.

For my money, the DB needs to have enough logic to ensure data integrity at a minimum. This I would define as part of the base tables.

I tend to prefer a relatively passive UI, and I think one can make a good argument that any functionality that involves only information, and no UI elements, can and probably should be coded into a DB interface layer of stored procs, views, functions etc. This promotes flexibility, reliability, and ease-of-maintenance via the 'single access point' model.

I mean, do we really want to replicate all of our business and data integrity validations at every point where the app touches the DB? And then let all the DBAs and developers skirt that logic via direct backend access? Both are recipes for trouble of you ask me.