I haven't used any of these, for a couple of reasons. Well, three I guess, the first being that I haven't found any real problems with using simple hash-based classes for everything.
in reply to Seeking inside-out object implementations
The second is that Class::Std and some of the others do some things that I don't trust to work reliably and not interfere with some other tool. They use rely on DESTROY, have a super-complex constructor, use lots of subroutine attribute magic, etc. I suspect bugs and bad interactions with other modules will be found in these complex additions.
And finally, I don't use them because, despite the name, they are the exact opposite of standard. All the Perl literature teaches programmers how simple hash-based objects work, and any OO Perl programmer can be expected to know it and read that code. Class::Std turns the world upside down (or inside out if you prefer) and provides a whole new mini-language to learn. It means another level of stuff that people will have to learn before they have any chance of understanding my code, and thus more training, more difficulty getting help in public forums like Perlmonks, fewer people able to contribute patches, etc. To me, that isn't worth the payoff.
Encapsulation? I'm giving them the source! If they want to break it badly enough, they will be able to.
UPDATE: I removed an earlier statement that Class::Std puts a DESTROY method in the UNIVERSAL:: package. Although the Perl Best Practices book does show that in the section on inside-out objects, the Class::Std module doesn't actually do it.