These "rules" do have exceptions sometimes. In my view, the point of "use @EXPORT_OK instead of @EXPORT" is to avoid cluttering up the user's namespace, and also to provide a bit more readability: use Config '%Config'; would tell the reader of the code exactly what is being exported, use Config; doesn't. I know some might disagree, but IMHO, some modules are so single-purpose that it's ok to export maybe one or two things by default, if their names won't lead to confusion (e.g. the name of the thing they export is traceable back to the name of the module). IMO, Config is such a single-purpose module, so it's ok to export %Config by default. Also, %Config is read-only, so "[the variables] can change under the hood, provoking horrible effects at-a-distance that are too hard to track and to fix" doesn't apply here either.

More exceptions might be: some modules exist for the explicit purpose of exporting a bunch of functions (e.g. to reduce boilerplate), and I also think it's sometimes acceptable to export certain variables on request (e.g. in a test script I might provide something like $DEBUG, where the fact that this is a global variable is not a problem).

I'll second this. Exporting constants in the form of named variables is often quite nice because you can interpolate them into strings, and they don't pollute your method namespace. The only downside is they don't get folded into constant compile-time expressions like happens with constant subs.

"The code is more what you'd call 'guidelines' than actual rules." – Barbossa, Pirates of the Caribbean.

++tobyink! The perfect quote for this thread, from one of my favorite movies.

"It's not how hard you work, it's how much you get done."

Yes.

That's why they are listed in perlvar

See Config and perlrun for more

Is it just to maintain backwards compatibility...

I would say not just for backward compatibility

There are times when global definitions are needed for an environment which will be different in a different environment... For example, we run three different environments for one website. Development, Test and Production. Apart from code that is being written or tested, they are identical except for a configuration file which contains nothing but global variable definitions of things that vary between environments (and comments so we know what they all are!). One such difference is which database schema each environment connects to, another is whether live emails should be sent to users, and so on.

Config.pm is a similar situation

For completeness, we don't export the variables. We declare them with our scope and access them with a fully qualified namespace definition. But we could get the same effect by exporting them instead ass all the variables have names that reflect their globalness.