Upvoted the OP, as it's an interesting meditation; but I disagree with most of it. In the Bad Old Days, if you found out you needed a 12-column string variable after you'd allocated 10 bytes of storage, you were toast.

Planning your data structures must come early in any project. I feel that if you find you need to revise extensively your data structures, you need to reconsider your entire approach. If it's just a matter of hanging one bag onto the existing structure then it's likely just writing another subroutine. If it's more than that, then it may well be time to throw out a lot of code and start over. I don't say that can't be painful.

That's why I spend so much time sketching data structures on paper before I touch the keyboard. By no means do I avoid all later redesign; but I try to cut down on the number of slash-and-burn incidents. When I fail, I refactor. Perl makes it very easy to minimize the damage from poor planning but I don't want to lacquer any real mistakes into the project's frame.

I don't hold with making every variable an object; that's fanaticism when carried to an extreme. (Here is a somewhat fanatic criticism.) I do use objects when they make sense: when I'm passing something persistent around, or working on it in many scopes, and especially when there's a natural hierarchy of classes in the data. I avoid creating verb or adjective objects; they don't make sense.

OP's point about sigils is well taken. One reason to avoid too many objects is to keep all variables from looking alike. But I'd argue against any change in syntax, any additional sigils. I don't rely on sigils to tell me what a variable contains; I expect them to tell me in what context an expression is evaluated. I do not usually employ both $foo and @foo in one place, or even one project. I don't welcome the Perl6 syntax in which %foo{3,4} is a hash slice.

I would also argue that one ought not use blessed array refs as objects. Traditional (if I may use the word) Perl objects are blessed hashrefs, with it being understood that these may well point to HoH, HoA, or more complex structures. More modern objects (again, if I may be excused) are the flyweight (inside-out) kind. While any code might use an older module (with traditional objects) but create modern objects, I'd hope that all objects created in a given project be of the same kind, one or the other.

We should not cavil at contrived examples; they're often better in discussion than the whole nasty real thing. But I have a difficult time with a plural object. When I'm in doubt, I try it in English: "Have an @employees"; "My @employees is an object in class ____". Maybe not so much. Calling an object, a data structure which is basically an array, violates the common understanding that an object is a thing belonging to a class and to which attributes pertain. A glass may contain many marbles but those marbles are but one attribute of the glass. A $roster may be an object; $roster->get_names_of($active) may return an array -- possibly of objects. Nor is there any objection to assigning that to the small-scoped @employees.

Conway is not generally in favor of bumps but if you feel you need to clarify, I won't object to $roster_obj or _ref. If you really do feel you need a blessed array ref, I'd like to see $employees_aryobj; it's fair warning.

On the same page, I'd like to mention an old guy who debugged all code by placing a sheet of paper on the right side, covering the comments. He wasn't interested in what the author said the code would do. Again, I expect the sigils only to tell me what will happen; not what the author's intent may have been. For the latter (since I'm not that good), I'll read the comments.

I intend no offense to say that the example given wants to have OO cake and eat it as well. I would not try to push() anything into an object. If I needed to do that, I'd $roster->push($new_guy); or better, $roster->hire($new_guy) or perhaps $new_guy->hire($roster).

If all you have is object orientation then everything looks like an object.