It's hard to distinguish between feeling clever and being clever. As with health issues ("feeling better" vs "being better"), science comes to the rescue.
I don't actually have any argument against what you said, in fact I agree wholeheartedly that the answer is the OP should empirically prove what they claim. Nevertheless, I hope you won't take offense if I use that as the starting pistol of a short rant. I find that kind of commentary irritating because I have a co-worker that thinks he is the more talented programmer. What's worse is that he is rude about it. I thin…
A large number of shorter functions, for example, can often be much harder to work with than one larger function that performs the equivalent processing. To properly understand such code (especially when it was written by somebody else), one must jump around from function to function, rather than just reading through one function from the top to the bottom.
Likewise, "less interdependency between classes" often translates to more complexity in other places. To get usable software, the classes will still need to be connected together somehow. Sometimes this is done via automatic dependency injection, which usually brings in a whole new set of problems.
Reuse is another "best practice" that often turns out to be bad in practice. It only works in those cases where the functionality being reused is truly general. Forced reuse of other, less-general code will often be problematic. The reused code soon starts needing to take into account slight variations in order to be used in several different places, and over time this builds up. This can ruin the code, resulting in a situation worse than had a bit of duplication been accepted.
Crashing code isn't necessarily a problem, either. Taking a fail-fast approach is often a good way to detect unforeseen problems while developing code, before it gets into production use. Even once in production, it's better to have software crash in an obvious and reproducible way, so it can be more easily and rapidly fixed. It's often best for it to stop working completely, than it is to continue on and perhaps cause many more problems (such as data corruption, or a huge amount of network traffic, and so forth). It can be much worse to deal with code that "doesn't crash", but only because the original programmers caught and silently discarded any exceptions that were thrown, or error conditions that were raised.
What you see as "good code" may, in a given context, actually be quite problematic. Perhaps your co-worker realizes this, and this is the cause for some of the friction you're experiencing.