I would not advocate this use for anything other than those applications that require the performance or memory gains or both.

Example: Data::Trie & Tree::Trie. Both of these modules use hash-based instantiations. The problem is that they require so much room for each node in the trie that they are next to useless for any practical purpose.

It's a simple case of using Perl to it's best advantage to achieve the desired goal. Blanket statements that all Perl OO modules should be hash-based completely ignores the possibilities of 3 or more other ways Perl's flexibility can be used to good affect to avoid having to drop into the nightmare of XS programming or the deep dependancies of Inline::C.

Perl6 will provide the Perl programmer with a much greater degree of control over the storage representation of data elements and aggregates and it will (hopefully) impose far less penalties for using OO dispatching. Till then, if your application needs to deal with large volumes of concurrent, in-memory instances, or you want to extract the best performance from a given class, using the flexibility that Perl's OO mechanism provides to achieve your requirements is simple practical.

Noone's advocating that every Perl class should be re-written to use an array-based representation to gain the 20%/40% benefits they can provide. If you don't need to optimise don't. If throwing hardware at the problem is an option; do so. It's just another option available to those that want or need it that can be safetly (and quietly) ignored by those that either don't need it or choose not to use for whatever reasons.