I think the short answer is that if you use interactive mode, the user will be occupied during the setup time. It's kind of like the mirror that some fast food restaurants put up near the counter to keep customers busy. If you loop through some data validation before continuing to the next bit of input, then user will have the sense that someone or something is holding his/her hand through the whole process. Your script will seem less frustrating to your customer.

Going further though, I really like Getopt::Long, and a clean non-blocking interface. With some params, you can have a non-blocking script that can be run, say from a batch or shell file. And if you use the script too, as an expert user then want to just throw down some parameter/value pairs, and get the script working post haste, you can do it.

You can actually implement both styles. You could make a bare invocation of the script go into interactive mode, and the inclusion of any parameters starting with - or -- be handled by GetOpt::Long/Short, or even fall back to interactive mode with any required params that are missing or incorrect.

Using environment variables for some of the parameters is not a bad idea either. Typically, these should be things that could change, but usually don't.

I say start with interactive, then perhaps add GetOpt::Long to provide an alternate interface that suits your own style.