I'm not sure it's necessarily bad practice. If it's user-level configuration, there should probably be a user-level interface to change it. If it's really more a set of constants gathered together similar to a C header file that may change but only rarely and at the hands of a programmer, then I think a module is a pretty good idea.

Package variables or constants can be very handy. Since it's older it might not have been written with the benefits of our, or the author may have wanted to be extra clear on where those values reside. IMO there's not much reason to bring in YAML, JSON, XML, Windows-style INI files, or some other non-Perl language to parse if they are just used as common constants unlikely to change.

If the end user is not a programmer and is being expected to change the modules, that's asking for some level of frustration. That frustration could spread to many people by the end of it, too. There should be a well-documented interface from the user interface to do user-level configuration. Whether that's a very simple .rc file, command-line options, a separate configuration program, a menu in the main program, or whatever, it shouldn't be in the code if a less technical end-user is meant to change it. That's not always the case, though.