The possibility that a programmer could make a mistake in the implementation of a paradigm is not an argument against that paradigm. The first part of your comment is very real and very valid, but copy-pasting is a potential issue regardless of your programming language.
Inheritance views the world as fundamentally hierarchical; you can divide things up into branches of a tree. A node on the tree either has all of a set of functions or none of them. Any code you put into Reptile will never be needed by a Mammal, and will never be inappropriate for an object that needs other things in Reptile.
But of course, that's unrealistic. Where would you put swim()? Where would you put fly()? Code reuse can't always be decomposed into a tree. And in an inheritance paradigm, you get ugly workarounds in that case -- cut and pasted code, nasty multiple inheritance hacks, or util classes. All bad things.
What you want are things coupled, not by convenient proximity in current function, but by logical relationship. You want a class that has swimming-related code and nothing else, that any swimmer can use without preconceptions about whether it's a Reptile or a Mammal. You want, in short, Traits.
Yes it can make your code more complex, but you can also use it to make the game more clean.
I do not make any similar claim about the validity of object-oriented programming, but I find your argument as a reaction to my comment rather silly. People make mistakes in paradigms all the time. Read The Daily WTF is you want to observe how badly people can mangle code. I'm not suggesting that all your problems with OOP can be solved by using more OOP, just as I'm not saying that the chance hat a programmer will misunderstand for-loops in Lisp means that we should throw out functional programming.