I don't mean that title seriously, of course, but I am really getting discouraged with some of the OO code (and programmers) that I meet. There's one OO developer that I know that, if we discuss a particular programming technique he hasn't used (coroutines, closures, currying, etc), automatically dismisses it as syntactic sugar and replies "I'd just write a class to handle something like that". Syntactic sugar??? Give me a goto and conditionals and I can argue that all of your loop constructs are syntactic sugar.
I've met OO programmers who I would expect, if asked to write "Hello, World", would make it a base class with subclasses to control the spoken language and methods to control the output location on the off chance that something like that might prove necessary.
My brother works with a programmer who is allegedly brilliant, but is so full of design patterns that he takes what should be a simple object model and creates an elaborate superstructure around it to handle every conceivable thing you could throw at it. To his credit, his code apparently works well, but his coworkers loathe him when it comes time to add the feature he inevitably overlooked.
Further, just because -- in Perl -- you bless a hash ref doesn't mean you have OO code. My first big OO project was an absolute piece of junk. Yes, I provided accessors and mutators for everything, sanity checking and used inheritance to avoid code reuse, but essentially I wrote procedural code and used a blessed referent to avoid a global variable. I don't want anyone to see that turkey, but it's still in production and being actively maintained (by me, which I think is an appropriate punishment).
I don't think OO is bad, but many programmers seem to think they've found the holy grail and kind of shut their mind down at that point. Once you've found the holy cup, you can stop searching, right?
I think that, for many programmers, giving them OO is like letting them drive. They forget that bicycles, walking, or not going anywhere are all acceptable alternatives. Unfortunately, just about everything I said above applied to me when I started learning regexen. I had some huge, incredibly complex ones to handle every possible special case that I could think of in these HTML docs I was parsing...
I dunno. Maybe I'm just a freak. I can have data hiding and encapsulation without OO. I could potentially use dispatch tables to simulate polymorphism (ooh...some people will yell at me for that). I might be able to avoid inheritance with cleverly exported subroutines. So why do I use OO? I really like self documenting code and I find that calling well-named methods on well-named objects tends to be self-documenting. My HTML::TokeParser::Simple module uses a factory to achieve this. Call me a conceited idiot (you'll have to take a number, though), but I think that was a very appropriate reason to use OO and a design pattern. There are plenty of legitimate uses for it, but too many illegitimate ones.