The two main reasons to use accessors is to provide a checkpoint where data can be validated before being used by the class, and to allow the internal format of the data to change without having to change the interface.

Do you need those checks when you access the data internally?
If the data format changes internally, will it be a hardship to change the other methods accordingly?

The answer is usually no, removing the need to use accessors internally.

Incidentally, recent experience has taught me that using an accessor internally can prevent a class from being inherited.

A class I was using inherited from another class in order to override accessors in order to pre-process (encode/decode) the data being exchanged. This worked fine with the XS implementation of the base class, since it didn't use the accessor internally, but it failed with the PP implementation of the base class, since it used the accessor internally, causing the encoding/decoding to occur twice.

This is more of a lesson in the need to use composition instead of inheritance rather than a lesson against the internal use of accessors, but inheritance is misused in this manner so often that it should be taken in to consideration.

If you want to use accessors internally for whatever reason (say to reduce code duplication), it might be useful to have accessors for internal use and accessors for external use (sub accessor { &_accessor }).