IMHO, Perl has enough syntax.

Exporting functions adds to what looks like core syntax even though it's not. Forcing a user of your module to explicitly import something, to access it through the package namespace, or to create and object with which to interact all give a better clue as to where different variables and functions/modules come from.

Exporting variables by default isn't any better. Your user is often writing the type of application for which you designed your module. There's often a lot of similar ideas for how to name variables when you and another person are working on the same problem. So please, don't give your user variables he's going to accidentally override.

So I'd say that it is best to export nothing by default. Exporting upon request is okay. Object instantiation is okay. Exporting nothing and requiring the namespace to be specified is okay.

Don't give me main::some_func() and especially not $main::some_var unless I ask for them. I don't want the potential conflicts, and I don't want to look back six months from now and have to search through my code and eight modules to figure out where $foo got set.

The subroutines might not be so bad for an experienced Perl programmer because they've had time to assimilate what should be core syntax and what doesn't look familiar. A new Perl programmer, though, is likely already overwhelmed with all that's in perlfunc and will only get confused further by what's provided by CORE and what's provided by your module looking alike. Variables are always an issue, though, so that's even worse.