There's more to it than that
Drupal uses OOP in specific places - for instance the Views module (a graphical point-and-click query generator). But beyond that, it's always had an object approach - for instance, the key content type, node, is an interface in the object sense: by implementing the interface for any new content type you care to make automatically gains all the advantages of being a node - the revision system, searchability, taxonomies, and much more.
But it doesn't use OOP to do this. It uses naming conventions for overrides and extending, rather than a pure object system. It works this way for a few reasons:
- while the API is not frozen, in practice it almost always evolves, which is to say that many, if not most Drupal 6 modules will probably work on Drupal 7 with only minor changes. Certainly that was my experience of all the transitions since 4.5. A change to pure OOP would have made module upgrades a great deal more difficult.
- it runs on a wide variety of platforms - everything from shared hosting to the cloud, and with a wide range of PHP versions; Drupal 6 continues to support PHP 4.4+ as its minimum requirement. But before PHP 5, OO was not robust. Taken together with the previous point, it would not be sensible to introduce OO as a language structure in a big way into the core for D7.
But I'm certain that Drupal will continue to use more and more OO structures with the improvement of the performance of OO in PHP, and as the need to support Drupal 6 fades.
Where there are API changes, it's not 'mashed up for no reason'. There are major advances in the capabilities which mean the API needs to evolve - for instance the database now has a much better abstraction layer. As a result there is support for SQLLite, an experimental module for using MongoDB, and work going on on SQLServer support.