This kind of assertion demands an example.

I live for examples ;-)

Bob writes a module to manage persistent objects:

package Persist;

...

sub uuid {
    # returns a unique ID for the object. should be
    # overridden by the subclass
};

sub load 
    # load object from persistent store
    $self->{_change} = 0;
};

sub save {
    my $self = shift;
    return unless $self->{_change};
    # save object to persistent store
    $self->{_change} = 0;
};

sub mark {
    my $self = shift;
    # mark and item as changed so it should be saved
    $self->{_change}++;
};
[download]

The documented API are the methods uuid, load, save & mark. The hash key _change is an implementation detail.

Now, Mary's writing a module for representing the state of vending machines. She needs the information to persist, finds Persist on CPAN, and decides to use this as her base class.

package VendingMachine;
use base qw(Persist);

...

sub _loaded {
    my ($self, $item) = @_;
    # returns true if $self has a $item loaded
    # in the machine
};

sub vend {
    my ($self, $item, $money) = @_;
    die "no items in stock" unless $self->_loaded($item);
    die "not enough cash" if $money < $item->cost;
    $self->credit($money)->eject($item);
    if ($self->{_change} and $money > $item->cost) {
        $self->give_change($money - $item->cost);
    };
};
[download]

Now, despite sticking to the published API, Mary is going to have a nasty time debugging her code. She'll have to go and read the source for Persist to find out that Bob's implementation detail ($self->{_change} = boolean value indicating whether an object has changed) clashes with her implementation detail ($self->{_change} = object representing available change in the vending machine).

Note this is not deliberate. Mary is not sneaking a look inside Bob's module and using the hash for her own nefarious means - it's an accident.

You get exactly the same issue with "private" methods. What if Bob decides to extend Persist to only load the objects when needed. As part of this he adds a _loaded method that will return true when the object is fully loaded from backing store. Without changing the published API his new version of Persist will break when used with Mary's old VendingMachine module - because it clashes with Mary's _loaded method. Nasty.

There are, of course, ways around these issues. You can use inside out objects to get around problems with attribute clashes. You can use alternate calling styles to get around problems with private methods. However these, and other techniques, all require a fair amount of discipline and expertise to use well.

Good encapsulation is a pretty darn basic feature of an object oriented language. In my opinion its absence hurts perl. It makes it harder to write good modular reusable code. It makes it easier for people to score points in those pointless language flame fests. Good encapsulation should be a basic part of perl (and will be in perl6... huzzah!).

Enough ranting :-) You might also find these exchanges on private attributes and private methods of interest.