Not having encapsulation means that it's really, really easy for someone to silently and mysteriously break your class by overwriting a hash key. I've had to deal with this and it's not fun. For smaller systems, it's less of a problem but bigger systems require more careful planning. Admittedly good test suites catch the errors, but they frequently don't tell you how to fix 'em.

The main problem with inside-out objects is that they're currently even more of a hack than Perl's current OO system. With clean OO, we wouldn't even be worrying about this.

I might add that Class::BuildMethods does not override UNIVERSAL::DESTROY and is very lightweight. It gives you encapsulation in a very easy to use manner and can be incorporated into existing classes. Further, the constructor is usually ridiculously easy to use. It's much easier than its counter-parts. The trade-off being that you only get one style of getter/setter and you can only store a single value (hashes must be passed as hashrefs, for example. By restricting the interface, the code is simpler and faster. You want three simple getter/setters?

use Class::BuildMethods qw/name rank serial/;

You can mix them with any others you want and add defaults or validation as needed.