I've seen alphabetical, but I tend to do it like this:

1. First, the pragmas, and Perl version number if necessary.
2. The "helpers"; things like List::Util, Readonly... very general utility modules.
3. The more specific utility modules such as File::Find, Text::Template.
4. The "This is why we're here." modules such as WWW::Mechanize, Benchmark, XML::Twig.

To me the idea is to start with the generalities that may be most applicable to all scripts, and then work my way toward the most specific modules to this particular application. At the same time I try to cluster modules that work together... together.

As I think about it, that's sort of a bottom up approach. Perhaps I should reverse the order to add clarity in reading the source, but I'm in this habit, and would probably only change if strong benefits are shown to be embodied in another approach.

One caveat is that there are a few modules which specifically state that you must use this one before that one. Inline::Files has to be listed before Inline::C, for example. In such cases it's important to # document the need, because today it may be obvious but tomorrow you (or I) will forget.

If I'm using a module for one small portion of a program, and not specifying an import list, I often # comment on what specific need this module is filling. That way if the program changes and that use is removed, I can quickly identify the module that is no longer necessary.

That's a habit that came from C, where it's common to list a whole bunch of header files to #include, and then quickly forget why they're being included.

I've considered # documenting along side my module uses which ones came from core, which I installed from CPAN, and which I wrote myself, but that level of documentation is more ambitious than I've been able to self-enforce.

Update:

I just checked, and unless I'm missing it, Perl Best Practices is silent on the issue of order of using modules. I recently re-read the book too, but that still doesn't mean I haven't forgotten. :) I wonder if the omission is because it doesn't matter, because it's too obvious to mention, or because it just wasn't considered.