I'm going to address each of these in a separate comment.

1. The reason I'd want one file is to make it easier to admin when updates are made available, which happens often.

   This is a fallacy. It's actually easier to manage changes made to very small items that are independent from one another. That way, you know that the change's impact is limited to a very small area. This is called decoupling, and it is an extremely important concept in change manamagement.

2. Testing can be done easier by simply running a separately named script.

   It is much easier to test small, independent items than it is to test a big complex thing. For one thing, you can more easily determine what the failure cases are. Plus, if you have a monolithic thing, you have to take into account every interaction every time you make a change. If you have a bunch of small, decoupled bits of code, you only have to worry about how the one piece you're looking at behaves. It's easier to work with 100 lines at a time than 10,000 lines.

3. The script and supporting files are hardcoded to run out of a specific directory, ...

   Just because it's only ever going to run with one set of parameters doesn't mean you should limit yourself to that. Hard-coding is almost never good, outside of a configuration file. For one thing, you can't test the code outside of a production environment. If you have a configuration file, you can test in a temporary directory and feel confident that it will work in the production directory.

I once spent two days adding configuration to a database connection class so that I could test it. I've yet to actually work with more than one database, but the ability to add 300 tests was absolutely critical. For one thing, I fixed a bug that had been annoying me (and my users) for three months. Impossible to do if I had to work directly with the database. (As in, impossible for me to make the effort to do it, not impossible from a technical sense.)