It does have its uses however.

In my game, I have a $universe hash, containing all the ships and maps and other info. The ships contain their component layout and stats, and the components contain their shapes and stats.

When calling functions, I only pass the sub-structure that is needed, but when it comes time to save the game or reload from disk, it only requires a single call to storable or yaml which never has to change. Much simpler than having a growing set of independent things to save.

There are, of course, still plenty of local variables in small scopes, but anything that has to outlive the program itself goes into my $universe.

it only requires a single call to storable

That's the justification for this amazingly sub-optimal design? ಠ_ಠ The hash key names are tight coupling, the location of the "sub-structure" is an implicit contract. That's badly reinventing the facilities of high-level programming Perl/ecosystem provides you with. It's perfectly possible to have a universe object that refers to other objects, but the design would be much more robust against changes.

The substructures are just unblessed object references to keep it simple. :)

I'm not sure what you mean by worrying about the key names or location of the substructure... each portion of the code concerns itself with one layer and knows where it keeps its own things. The mapview has a 2d hash with ships in it, and doesn't care about the details. The shipview has a ship ref with components in it, and doesn't worry about the details. The aim screen has a single component ref and is at the bottom level of detail (its also stacked on top of a mapview so you can see what you're aiming at).

Its not an *enforced* separation, but I like the straps on my straightjackets to be loose :)