It's a nice timesaver to use it to handle simple accessor / mutators without having to write them explicitly

To start with, IMO good OO design is not making an accessor/mutator for all your object fields. I almost never make accessor/mutator functions like you show. Since some values should be read-only (only accessor), and IMO mutators should not mearly be means of setting object fields, but should be tied to the behavior of the object instead.

Perhaps part of my problem is that a lot of my ideas come from Damian Conways 'Object Oriented Perl' (Manning 2000), which is perhaps outdated.

The problem could also be that Damian is insane!!! Personally I love that book, but he sometimes goes over the edge telling you all the insane stuff which can be done, but probably shouldn't. When I had my junior programmers reading that book, I told them specifically to skip most of the middle of the book since it was just full of strange tricks which we would likely never use (of course they were free to read it if they wanted, but I forbade them to use that knowledge without really really really good justification).

Or maybe AUTOLOAD can be used for a lot of neat tricks in little scripts, but becomes quite annoying for large software projects.

My feelings is that AUTOLOAD is a tool for which there are only a few good uses, and those are really fringe cases which will very rarely come up in real world coding scenarios.

For instance the NEXT module would not be possible without AUTOLOAD and IMO that is a excellent usage of it. I recently answered a question about dispatching SUPER calls to mix-ins which used AUTOLOAD (and was very much inspired by the code in NEXT). In Class::Trait::Base I used AUTOLOAD to make sure that calls to SUPER:: were being dispatched correctly, and I think Class::Role && Class::Roles do similar things.

I feel these are justified usages of AUTOLOAD, since there really is no other way to accomplish them without AUTOLOAD. I do not think it is a justified usage of AUTOLOAD to save typing time (auto-created accessors/mutators and delegation), since I think many times that leads to overly clever code which is a pain to maintain and many times impossible to extend (ie - subclass).

However, these are all purely my opinions, and to be taken with a HUGE grain of salt.