If you hate it, you have not grasped it, plain and simple.
Yeah, here's the problem. You and everyone else already things they understand OOP and that everyone else just has it wrong. The believers will insist that any OOP failure is a failure to truly understand OOP.
The truth, of course, is that no one understands OOP because no one can agree on what constitutes OOP. The Smalltalk folks will complain about how Java and C++ got it all wrong and ruined a good thing. The Java gurus will say that they've got the one true OO language. The Self guys will say that everyone else got it wrong from the start and that classes are unnecessary and add needless complexity. Converts still using C will argue that it's not the language, but how you use it that makes something OO.
You use a simple example to sell us on OOP. Others claim that simple examples are what lead to the masses misunderstanding the true power of OOP and that you don't really see the benefits until you're working on a very large application.
The design patterns zealots will tell you that it's the first step toward true software engineering. The rest will counter that design patterns are just complicated ways to work around the flaws in C++ and Java or that patterns are just missing language features. Others will claim that they can be helpful, but that their overuse has caused nothing but harm.
Favor inheritance or composition over the other? Always use accessor methods or are they unnecessary redundancy/overhead sometimes? Was multiple inheritance a mistake, and Java got it right with single inheritance? Is inheritance a mistake entirely as it can break encapsulation, or is that an unfounded criticism?
If you can not work with OOP and/functional concepts, your mind is stuck in simple thinking, you only get around that by actually using the stuff you hate.
A lot of people hate OOP because they've used it for decades, seen the OOD fads come and go, best practices turn in to dangerous pitfalls, and other ridiculous industry trends. Now, rather than selling us on the solution that will allow us to finally reap the benefits we were promised by OOP salesman, they're selling us solutions to help us clean up the mess OOP left on the rug.
Just one more example: You've not see spaghetti until you've seen a dependency diagram on any moderately large OO project. Enter dependency injection, the solution to the problem caused by various OO fads. If you're sold on DI, or one specific framework, you'll say that it's not only necessary, but we should have been doing this all along. If you're sold on OOP and skeptical of DI, you say that DI is only necessary for those that don't understand OOP.
I can't say that I blame the anti-OOP crew. I just might be one myself. I say "might" as it really depends on what variant of OOP you've got in mind. Not that that's easy, as I don't think any one developer has a single coherent vision in mind. I suspect that if I asked 10 developers, I'd get 12+ answers.