I've seen misuse of "old" coding techniques (e.g. "nested-include hell", turning .p files into internal procedures, etc.; list is nearly endless) and "new" ones (e.g. multiple layers of abstraction for no good reason).
In general terms, I think the person wielding the tool is at least as important as the tool itself; specifically, their experience, skill, discipline, attention to detail, knowledge of good patterns and practices, and concern for writing good maintainable code.
Other people here can give you more specific reasons to choose OO techniques and you've already heard some. But I can say from experience that people who are new to OO and who don't have a solid grounding in the concepts will write bad code that will likely have to be rewritten. Shiny and new, but bad. That certainly isn't an argument against OO patterns; just an observation.
There are things we do in our application which it would be very hard to reproduce procedurally.
I agree. I am starting to dip my toes in this OO world. After examining and playing with a
UserTableStatistics class from Mike Fechner and Tom Bascom on Github, I've started writing code of my own that follows a similar pattern. It's actually quite elegant (the pattern, not my code
). It makes collection of data from multiple databases much easier and more flexible than the procedural equivalent.