|Do you know where your variables are?|
Is it still true that Moose adds a significant startup time penalty to my script, ...
This is all relative actually.
If you talking about a vanilla CGI script that may have tens, hundreds, if not thousands, of invocations a minute, then yes Moose startup will be a problem. It will mostly be a problem because the 1/2 to 1/3 of a second (depending on your machine specs) Moose adds to your startup will be compounded by many concurrent invocations and conspire to slow everything down.
If you are talking about a command line application where the user expects an immediate response at startup (meaning it is not I/O bound in some way with a DB connection or something), then it might be a problem. I say "might" here because of two things;
First, if you can present the illusion of response (print a banner or something during the BEGIN phase) then the time taken for the user to see and process this will likely be longer then it takes Moose to load. This is a technique used all over the place in UI design, basically the simplest form being a loading animation.
Second, since a command line app is probably not going to be used concurrently by many people on the same machine at the same time, it won't suffer the resource starvation that vanilla CGI would. Which means that on a high powered server or something, you might not even notice the startup overhead.
And then lastly, if your talking about some kind of periodic script or cron-job, which has to startup, run and complete in a given time window, then Moose is probably not a good idea. I say this because the periodic script might awaken during a time of limited resources or of otherwise busy activity, at which point Moose startup might penalize you too heavily.
Of course the only real way to tell is to try it yourself and see. Run perl -MMoose -e 1 in your target environment and see what happens (make sure you have the latest version though, lots of performance improvements are happening).