It's possible to write badly designed code in any framework, but abuse of a framework is not a justification for not using the framework at all. In my own 30+ years of programming, I've found OO to be as big an improvement over its predecessors, as block-structured languages were over FORTRAN and BASIC. Is OO going to make your life significantly easier for a two-line MySQL access? Of course not, but that's a toy example. What happens when there are hundreds of tables and thousands of queries? Then a framework like Hibernate looks a lot better than the Perl/PHP mess we'd otherwise end up with.
You've never found a "class" from someone else worth anything? I use hundreds or thousands of classes written by others -- libraries like SAX, DOM, JAXB, Xerces -- on a daily basis. Sure, there are badly designed classes written by newbies here on YA!, but so what? They're just learning. As someone much wiser than I once said: "Good judgment comes from experience; experience comes from bad judgment." My coworkers produce classes I have no trouble using. Maybe you need to find a place where your peers are as good at programming as you are?
Classes are a great way for organizing code. Polymorphism/inheritance is a great way for reusing code -- reducing complexity, enhancing readability, and lowering maintenance cost. I agree that these great tools do no good in the hands of people who don't use them properly, but I think we disagree over how common it is to find usable work by others.
Let me give an example from a fairly major project which I've worked on recently: a loan servicing system. It has three main classes of receivables: curtailments, monthly amounts due, and fees. All of these inherit from a common Receivable class. The behavior of ALL types of receivables is in the superclass (e.g., when a receivable gets paid, record a Transaction for the payment being allocated). It is overridden in bits and pieces in the subclasses (e.g., fees don't pay down principal, curtailments change the loan's schedule going forward, etc.). The behavior hung on the Fee class itself isn't every last detail common to all receivables, it's just the parts that apply only to Fees.
In a non-OO language like C, I'd have to either have tons of duplicated code, or functions full of if-statements (if it's a fee, do this, otherwise do that). The former is expensive to maintain, the latter is difficult to read. Neither of those non-OO approaches scales well to the real production system which has more than 30 fee classes underneath the generic Fee. The organization of that code in an OO structure is much more straightforward, and it does scale to the full-sized problem. OO gives constructs that map well to the way that people naturally think about the world (hierarchies of types: thing -> vehicle -> car -> ...; instances of types: my Prius, your Prius, ...).
I still write lots of Perl scripts, and occasional bits of PHP. My Perl projects tend to be small, though, and I find Perl OO kind of weak and clunky, so the benefits don't justify the overhead -- just as with your PHP MySQL example. But for big real-world projects, OO confers significant advantages, which are critical to the efficiency of development and holding down the cost of maintaining the solution going forward. On top of that: if I weren't able to make use of large class libraries written by others, I'd be a lot less productive because I'd have to keep reinventing the wheel.
@M