Let me expand on this just a wee bit.

One of the developers reporting to me wrote a very useful script that we needed. However, he wrote it as a script rather than as a module. What that meant is that I could not embed it into the overall perl project that we are using - well, not easily. I rejected his implementation (would not sign off on it) based solely on this aspect. He is converting it into a module right now.

Yes, it's that important.

He will also create a sample script that all it does is convert the command line parameters into arguments for calling the function in the module. So the external behaviour will be unchanged, but the internal behaviour will allow us a lot more flexibility. We're going to be using the code in ways I'm sure he hasn't imagined (because if he had imagined, the code would have been a module in the first place). These other things include things such as reading the parameters from an XML-like datastore, or reading lists of files from the filesystem. The latter is one he thought of, the former is not.

Thus, I'd suggest creating a tarball that included the module with all the functionality, and a wrapper script that allows you access to that functionality from the commandline. It would also serve as an example for those who wanted to write their own scripts to do other things, or to get input from various locations.