My naive though is the following: an external script seems less convenient to retrieve results than returning them back from a subroutine via a reference. However if I start pasting my code as a subroutine in a few different scripts, any improvement I make will have to be updated in all of them.

This is addressed very directly in Elements of Programming with Perl referencing an earlier subroutine created called commify :

"Before we delve into the mechanics of building a module, let's consider a simple case that illustrates how a module helps us reuse our code. Recall the function we wrote in chapter 10 for putting commas in numbers. This is a good little function that does one—and only one—thing. Perhaps we have already reused this function by copying or pasting it into other programs where we needed such a function. Reuse of code is a good thing, but this kind of reuse is problematic. First, when we decide we need that commify function, we need to locate one of our previous programs to copy it from. This is not very convenient. Secondly, what if we eventually find that this function has a bug in it and doesn't properly commify a certain numeric input? Now we have to fix this bug and find all the other programs we've written and fix the function there as well. Wouldn't it be better if we could simply write this function in one file and then use it from any other program we create? Well we can do just that."

~Andrew L. Johnson, Elements of Programming with Perl, Page 272

I just did this today for the first time so I thought I'd share what I learned along with a few references.

Perl has a few tools that will quickly and pretty easily build a module template for you. You can download Module::Starter, a command line tool, that will look like this the first time you run it:

Usage:
    module-starter [options]

    Options:

        --module=module  Module name (required, repeatable)
        --distro=name    Distribution name (optional)
        --dir=dirname    Directory name to create new module in (optio
+nal)

        --builder=module Build with 'ExtUtils::MakeMaker' or 'Module::
+Build'
        --eumm           Same as --builder=ExtUtils::MakeMaker
        --mb             Same as --builder=Module::Build
        --mi             Same as --builder=Module::Install

        --author=name    Author's name (required)
        --email=email    Author's email (required)
        --license=type   License under which the module will be distri
+buted
                         (default is the same license as perl)

        --verbose        Print progress messages while working
        --force          Delete pre-existing files if needed

        --help           Show this message

    Available Licenses: perl, bsd, gpl, lgpl, mit, apache

    Example:

        module-starter --module=Foo::Bar,Foo::Bat \
            --author="Andy Lester" --email=andy@petdance.com
[download]

Building a module for personal use will only be a few lines:

$ module-starter \
--module="Foo_Email" \
--author="You" \

...
[download]

Others will correct me surely but for your own use you wont need much more than that. Dive into the directory created by module-starter and everything is right there waiting for you to add your code. You'll quickly realize it's not as big of a deal as you thought it was and really worth learning. How do I know this? Because it just happened to me. :-)

Good luck — have fun!

REFERENCES:

• Elements of Programming Perl, Chapter 16: Modular Programming
• Effective Perl Programming, Chapter 9: Distributions, Item 80: "Don't start distributions by hand."
• perlmod
• Afterwards you can follow up with: RFC: How to Release Modules on CPAN in 2011