Suppose that you want to create an interface to a dbm. Making it look like a hash is an obvious way to do it. (If you try to do it with nested data structures you have trouble, but let's ignore that.)

Now suppose that your dbm offers some useful features that hashes don't - like granular locking for cooperation between processes. How do you expose that naturally? You can't extend the tie solution to do it. The available behaviour for a hash is fixed by Perl's syntax - to get something with extensible behaviour you have to make it obviously extensible from the start. The native datatypes aren't. So you either tell people to peek using tied (wrecking the illusion) or else (more efficiently) you don't pretend to be a hash from the start.

With this example in mind, here is my criticism. Perl's syntax creates a strong image of what a built-in datatype should look like. Built-ins are not extensible. tie allows a pretty effective illusion of a built-in. But if you have something that is a lot like a built-in, but its behaviour needs to be extended in some direction, Perl simply doesn't have a clean solution. Those two notions simply do not conceptually go together in Perl, looks native means isn't extensible and vice versa.

It doesn't have to be that way. For instance in Ruby the native datatypes can trivially be extended, and if you need a different implementation, then the MetaRuby package makes it easy to write new datatypes that behave like a built-in. This is the equivalent of tie except that no new concept needed for it, and there is no conflict between using it and extending the behaviour of your new thing in some interesting way that looks nothing like what the native datatypes do.

Of course you give up autovivification because the syntax no longer gives hints for the datatype. But then again you can swap between hashes and arrays more easily. And, of course, by not making it look hard you give up the appearance of being a genius for figuring it out...