Deep structures like that seem to shout out OO to me. If data is hierarchial enough to warrant a deep structure, there must exist an organizing principle that can supply a class name for instances of data at each level. The advantage is that that conceptually flattens the huge data tree.

Your example data structure suggests exactly how that should go. Galaxies are gravitationally bound clusters of solar systems, rubble, dust and gas. Solar systems are gravitationally bound clusters of stars, planetary systems, rubble, dust and gas. Planetary systems are gravitationally bound clusters of planets and moons . . . with perhaps a little rubble, dust and gas.

Of your goals,

1. A non-programmer who knows even a little astrophysics will immediately understand what OO code based on that does. One who wants to expand it to superclusters or add a black hole to their galaxy's center of mass will have plenty of guidance. I wouldn't trust the coding details to a non-programmer, but they will understand well enough to provide specifications and realm advice.
2. There is clearly a fundamental base class, "Massive Object", and a base collection object, "Gravitationally Bound Cluster", which is itself an even more Massive Object. The various subtrees are instances of these, subclassed by other properties into "Solar System", "Star", "Planet", "Rubble", and so on. The subs which may act on a part of the tree are simply the object methods of whatever occupies that slot. Many of those will be inherited from the base classes. In particular, the methods of Massive Object can probably be called by any element of the $galaxy tree.
3. As long as you don't fiddle with pseudohashes in defining your classes, they won't bite. The OO principles used here are supported by any Perl 5.