I was as well. My point is just that not everyone works on the same things or has the same resources, and there is no global optimum. I'm generally in the “more functions, fewer classes, minimize inheritance” camp personally but the most important underlying principal is remembering that methodology is a tool which is supposed to help, not hinder, and adjusting based on local conditions.

Part of the value an experienced developer brings should be having a good sense for when a particular approach is a good fit for the problem at hand and being willing to say that whatever you're doing needs changes. This can be tricky because methodologies often have a quasi religious aspect where people take the decisions very personally but the worst project outcomes I've seen have been from cases where people treated the status quo as holy writ and refused to consider how problems could be avoided or transformed by picking something different.

Ironically, I think most people in that situation would agree with you that they "probably have a problem" -- the difference is that they see the problem as the important thing to focus investing resources into solving whereas you see its existence as an inherently poisoned entity that must be conceptually purified. While both parties would probably agree on the existence of /a/ problem, the definition of what needs to be addressed and how is likely to differ, and I can't say that the latter attitude is the norm at any high productivity engineering organization I've ever worked at, built, or encountered.