I'm not horrified, as I've had similar thoughts to yours lately. I do think you might get a better response if you could extrapolate on your reasons for moving the logic into the database. Maybe a blog post?

Your argument that a schema w/ keys is already "business logic" could be refuted with the stance that the database is actually the "business model", and the logic is in how the rows and columns are updated, which takes place (and should) in the "application", not the "storage mechanism".

What I imagine is that because SQL was not originally conceived to be a turing complete language, the possibility of having your business logic in the database was simply not there.

The possibility now exists, and I've run into projects where stored procedures do a lot of heavy lifting, but I've never seen an example where stored procedures do all of it. After all, you wouldn't write your UI w/ a stored procedure.