Oft times questions of the form "is X better than Y?" are largely meaningless without context information. Are pickup trucks better than minivans? Well, it depends whether you're planning on hauling around lumber or half a soccer team's worth of children. Looking at other replies and your responses it looks as if you had two questions; I'll try to answer both.

The use keyword executes code at compile time where as require does it at run time. Almost always you want the former, though I can give you an example of where I personally want the latter. I have a class called SQLLink that is fed information about a link table in a SQL database. Among the information there are table specifications, but also the class names of the parent and child classes. I use 'require' to compile the code for a parent or child class when SQLLink needs to instantiate such a class.

eval "require $parent_class"; die "$@\t...$parent_class barfed" if $@;
eval "require $child_class"; die "$@\t...$child_class barfed" if @;
[download]

You need the idiom of the string eval (to the best of my knowledge) to get 'require' to do its bare word behavior of locating a class based on your lib paths, and because eval traps errors you'll want the 'die' afterwards to make sure that the file compiled successfully.

Now to address what would seem to be your real question, whether tis nobler to pollute thy namespace, yada yada outrageous fortune and so forth. Personally, I really hate namespace pollution for the same reason you do. I do not want to see "foo()" in the code, not be able to find "sub foo { ... }" anywhere in my code, and notice that there are ten library importations at the top of my code and have no clue where to start looking to figure out from where foo originated. To refer back to my 'context' assertion from the first paragraph... It matters whether you're writing a throw away script that fits in a single screen full of code that you don't plan on using after this afternoon, or if it's a serious attempt at a core library to which you (and other people!) will be frequently returning, or worse still infrequently, as the longer you go without looking at it, the less likely you're going to remember how it worked.

Fortunately, there is what I deem to be a very good compromise. Any module worth its salt not just jams an @EXPORT variable full of junk, but also populates an @EXPORT_OK variable which specifies which names it is ok to explicitly export. I think the really nasty namespace pollution comes is the implicit kind, but explicit pollution is ok in my books. If you come across "foo()" in your code, and then you go to the top of your library and you see...

use Some::Module qw(foo);
[download]

it is obvious at a quick glance from whence foo sprung. You also know from that statement that foo was the only thing that Some::Module exported, since no implicit exportation occurs if you specify anything explicitly. So, I believe you very justified to eschew implicit namespace pollution, but give the explicit variety a chance. I think you'll like it.