This thread made me laugh: Say it with me “Databases don’t scale, application servers do.”  We could both eat grass too, but it probably doesn't mean we're cows.  Any mutli-threaded app can scale.  I've crashed far more app servers than database servers due to merely running out of resources though.

Put business logic where it makes the most sense.  If you change your business logic as often as you change your shorts, then put your business logic wherever you can develop it the quickest.  Often that is a personnel decision, not a technology one.  I.e. if you have 3x the .NET developers as SQL developers, then maybe it should be coded in .NET.  If the reverse, then code it in SQL.  In many cases either place would do just fine.  In SQL 2005 the line is even more blury.  Please don't design your apps solely based on the possibility that you might someday have to port your app to another database platform.  You're just as likely to have to port your GUI to C-flat-plus-minus in a few years. 

Keeping your data consistent and clean is done at the database level and that often goes far beyond mere referential integrity.  It's also common to put business logic in the database if you're tables are being hit from multiple apps or other database jobs that may not have their own GUI. 

Do you really want 3 different development teams coding "similar" business logic for the same set of tables?  The devs probably don't code in the same language and there's a pretty decent chance they won't even speak the same language.  Even if they did, you're unlikely to have them all developing at the same time, so that one small table change for team A could completely destroy team B and team C's GUIs if they all wrote their own business logic.

I think this author has sat in on one-too-many theory-laden seminars and could use a bit more time in the trenches of database-centric application development.  The article is a year old though, so perhaps it was a passing fad.