|Don't ask to ask, just ask|
It sounds like you have a reasonably good grasp of how objects can be used, but I think you are missing some of the finer points of using objects.
I recently used objects to much success in a math API. The use of objects allowed me to create "super data types" which both needed to be opaque to the user and also required complex operations which weren't usually available from the standard datatype.
I'll illustrate a couple cases.
First, let's describe the project as abstracting lots of math operations on lists of time-aligned numbers. Sure, this could be done with an array of hashes like:
But you still need to be able to provide operations on those values. The example being when I want to pull "all the values" or "all the timestamps" out of the object. You could use map here pretty easily, but you'd have to replicate that code every time.
When the code gets more complex, like "how do I add all the values from stamps X, Y, ... from two sets of values?", you quickly start needing to come up with componentized code.
How about the actual data in the objects? Another benefit of having objects is you ensure everyone is using the API the same way. You provide "gettrs" and "settrs" for your API, so hopefully your users are not manually pulling data out of the objects (see Ovid's "thou shalt not covet thy objects internals"), and if you change the methods behind the magic, the users won't notice.
Additionally, by abstracting away the guts of the object, you get niceties like immutable values:
In this case, even if the user dumper()'s our values, they can't see what they are, and you force them to actually use your methods (go on, give it a try).
Furthermore, by using objects, you can change the way math actually works. Lets say you want to have a switch that adds .0000092 on particular platforms because of a bug you know in that platform. When you have methods that do the work for you, you can have intelligence in the methods that the user doesn't have to know about, or might not understand. For them, they still have $obj->series_add( $another_obj ). They don't know what's going on, and that's generally what people who write robust API's hope for.
The last thing that I want to hit on is the fact that you can use a module like Params::Validate to incorporate testing into each and every operation your code uses. Cases you never expected to occur can and will occur in the code that uses your code, and your tests will spit out what went wrong, and give you a very good idea of where the bug is. (this of course doesn't take into account that having P::V in your objects will allow you to autogenerate documentation from the validate() and validate_with() calls, and make your code oh so much nicer to work with)
OOP is usually a little more of a headache (I'd estimate it takes me another 15-20% more coding time up front), but the payoff is huge in the end. Users aren't mucking about with your datatypes, fixes to code are visible in all code which uses your API, and it lets you really set a "substrate" for which others will develop their applications upon. I personally always take that performance hit up front just so I have a better environment to work with down the road.