The example given was using object methods as an interface to an object that encapsulated an array with a statistical attribute.

My point was that, for the programmer using this module, it might be more familiar ground for the object to look and feel (from the outside) just like a plain old array. In my example, there isn't a new API to learn. And code using the object will look and feel pretty basic. A Perl programmer plays with arrays all the time. We're all pretty much used to the "interface" to arrays. In this case, the simple (for the programmer utilizing the module) approach is to carry that idiom forward seemlessly, or transparently for simplicity's sake. The only thing to learn would be what object method to use in accessing the array's statistical attribute.

Yes, nothing has really changed internally. But externally, the module's user only has to remember how to play with an array.

But this is all a big tangent on the OP's thread. I have to agree with the OP that the complexities of a datastructure are often better dealt with through layers of objects. However, I don't entirely agree. The objects should be used to simplify life, not to make it more intricate. Occasionally a complex data structure provides simplification rather than undue difficulty. It's not always bad to let the cat out of the bag.