One problem I've had when doing this is that strict no longer provides protection against a typo in the variable name. At least by using an import you are making the name available unqualified at compile-time so that perl can check it for you.

use Foo;
print $Foo::fooo; # woops!
[download]

One argument for using a fully qualified name is that you prevent a name clash with a variable in the current scope, although I would consider it bad style to reuse a variable name in two scopes, where it is used in both and from both. It would also indicate to me that the variable has perhaps been badly named.

As usual it depends on the situation, but you need to be aware of the pitfalls of the approach you take. One module which uses package globals to modify its behaviour is Data::Dumper, which has variables such as Purity and Terse. These have quite common names, but you wouldn't want to export them into the current package because they are only used by the Data::Dumper code.

Data::Dumper on the other hand does have a more 'modern' interface to the same functions by using an object to store the settings which has the advantage of allows different callers to use different options.

--
integral, resident of freenode's #perl