Yes, exactly. Lots of people miss that, despite the inclusion of encapsulation and inheritance, a lot of OO code is essentially just changing the semantics. This of course is bad OO, and 'good' OO will make some use of the new syntax, rather than just using it as sugar. The basic conversion is (pseudocode, not Perl, not C):

foo($alpha,$beta,$gamma);
// into
$alpha->foo($beta,$gamma);
[download]

These concepts can be used to do pseudo OO in C (a non OO language by all means), whereas many think you need C++. However, you lose the encapsulation so you have to have extreme discipline in that regard (just calling functions and refusing to twiddle structure bits) and you can't leverage inheritance without using function pointers to simulate method lookup tables. It's when you start using function pointers for virtual-ness when it starts to get ugly, very ugly, so you might not have gone there in the first place. Bad!

So, anyway, what I mean to say is that while encapsulation, inheritance, and polymorphism are viewed as basic tenets, the simple idea of "keeping data together" (i.e. C structs or Perl nested datastructures such as an HoH) are perhaps some of the most widely used -- a "non OO" OO. It quickly devolves into basic proceduralism., especially if you have already broken encapsulation with too many trivial getter/setters. Inheritance, too, is widely overused.

What was I saying? Ah yes, as you say, it's just proceduralism by any other name -- but a HECK of a lot cleaner than base proceduralism if you want the same power and safety in your data structures.