I'm curious about how you'd respond to that.
Keep in mind I am not a DB expert nor a heavy-duty rails user, so take what I say with a grain of salt.
In a lot of ways I see the whole debate as a matter of control, and which side of the debate you fall on depends on where you exert the most control.
Database owners (DBAs and schema designers) want the rules applied at the lowest possible level. Allowing the rules to be enforced at the application level scares them because that means /every/ application needs to follow the rules. Since the apps can be written in any language using any framework, the only way to provide consistent rules is at the DB level.
Application developers have different perspective, particularly open source authors or anyone writing against multiple databases. Since /any/ database could be used by the application, moving the rules out of the application means that that they can't depend on the rules being enforced at all. Different databases have different capabilities for rule enforment. So if you want your application to run on anything from Sqlite to the top end Oracle server, the rules must be in the application.
So where do you put the rules? David HH (the author of Rails) suggests that for single point of entry database with a single app (or at least a single framework), having the rules in the app code is not a bad idea. However, he doesn't disagree with the rules in the DB approach in enterprise DBs.
Robby Russel (a big Rails user and owner of Planet Argon, a Rails friendly ISP) is a big fan of putting as many rules as possible in the DB, and he does so in all of his DB applications. Of course, he sticks primarily to Postgresql, so he doesn't have to deal with the cross database platform problems.
So there you have it, Rails is able to support either approach.
Where do I stand? Putting all the rules in the DB only seems to leave the app with only an anemic ability to validate. Putting the rules in the app only leaves the DB without the information it needs to help. I would put it in /both/ places, but express the rules at a single point, probably using some kind of domain specific language that could easily be translated to whatever database or application language needed it. (You can look here [link|http://onestepback.org/articles/lingo|http://onestepback.org/articles/lingo] to guess what I would use to create the DSL).