Set theory is hard science. On the other hand, a grapevine of stored procedures with no code reuse beyond copy-paste aren't any kind of science. I'm not even sure they are any kind of engineering.
You are raising an interesting issue here: does DRY principle apply in db dev. Not sure. Db dev its closer to configuration. Anyway I won't advocate too put all the logic in the database, so I won't get a grape wine, maybe just a fruit plateau, with some duplication but not to much.
Related to your point would be an argument that software engineering is more productive when treated as a "hard" science (which I take to mean something like "rigorous justification of all steps" or "clear derivation from principle").
I don't think that's true at all, as evidenced by pretty much every successful software product ever (including the early relational databases, I should add) but would be curious to see the counterargument.
Software is a complex beast with multiple aspects. The UI design can Bree taken seriously but is no hard science. Many interesting parts just can't relate to hard science, even where you have algorithms. But when handling facts data you have the possibility to ground yourself on hard science, and should. It would be a stupid crime to build a tower without grounding what can be on maths and physics, no?
I have to add that this issue is much deeper than a simple efficiency issue. A perfect db with 100% availability would still not be well matched to an object system.
I listened to a podcast from 1990, the guy said "the problem with objects is that we don't know what they are". I just finished SICP, and it seems it is the same conclusion: objects with their state, their messages, their multiple parents, their instanciation, are not a proper model for many or most cases in software development.
Example of proper models include types, text files, streams (pipes), modules, maybe services.