Well, Obviously it's somewhat slower to load:

$ time perl -MGetopt::Std -e 1
0.07user 0.00system 0:00.07elapsed 97%CPU

$ time perl -MGetopt::Long -e 1
0.19user 0.05system 0:00.23elapsed 102%CPU

$ time perl -MGetopt::Declare -e 1
0.59user 0.08system 0:00.67elapsed 99%CPU
[download]

For the option parsing itself, that'll depend on how much extra work you put into the declaration (action blocks, more sophisticated parameter checking, etc.). Certainly it isn't the option-processing answer to every problem, but if it's easy to code and read and the startup/parse hit (amortized over runtime) isn't crucial, it is certainly worth looking into. It won't compete with Getopt::Std for efficiency on simple things, but there's a boatload of functionality I didn't mention -- here's the clustering example from the docs:

For example, given the parameter specifications:

            -+              Swap signs
            -a              Append mode
            -b              Bitwise compare
            -c <FILE>       Create new file
            +del            Delete old file
            +e <NICE:i>     Execute (at specified nice level) when com
+plete

The following command-lines (amongst others) are all exactly equivalen
+t:

            -a -b -c newfile +e20 +del
            -abc newfile +dele20
            -abcnewfile+dele20
            -abcnewfile +e 20del
[download]

Also: optional parameter lists, abbreviations, mutex directive (only one of a given set of options may appear on the command line). And, it can be told to parse a config file rather than @ARGV, and can return the parser object itself so you could use it to parse multiple such sources. There might even be a kitchen sink in the source somewhere, and you never know when one of those will come in handy.