Well, that's a matter of taste.

It is also a matter of taste whether or not to use lots of global variables.

Note that there is such a thing as bad taste.

Comparing (over)using @EXPORT and globals is actually quite appropriate. The basic issue is the same: increased opportunities for code one place to collide with other code through action at a distance. When Exporter was first written, this was not understood to be a problem. But now it is, which is why its documentation now says,

Do not export method names!

Do not export anything else by default without a good reason!

Exports pollute the namespace of the module user. If you must export try to use @EXPORT_OK in preference to @EXPORT and avoid short or common symbol names to reduce the risk of name clashes.

(Emphasis in original.)

I'll admit to barely glancing at the original code, there may be tons of other problems with it. Some of which may be debatably problems (I don't believe that base is particularly important), and some of which may be obvious areas for improvement. But I didn't notice.

This is because my practice is to hold answers to a far higher standard than questions. After all a question usually admits to not being a good example. An answer holds itself up as an example of how to do things. So when I see a long question and a short answer, I often skip to the short answer and may comment if I don't think it should be offered as an example of how to work.