What I'm wondering is whether this is considered good Perl coding practice?

I think you're asking the wrong question. You should consider asking (yourself) the following:

1. Does it work?

   Given this is an existing project, I'm gonna assume the answer is yes.

   So then you have to ask yourself: what are the risks involved with changing it?

2. Is it difficult to maintain?

   Reading between the lines of your description, I'm gonna assume the answer is no.

   If you need to change the value of an existing configuration parameter, you go into the .pm file and edit it.

   If you need to add a new one, you edit the .pm file and add it.

   That doesn't sound particularly hard to me. In fact, it sounds identical to the process of maintaining a configuration file in some other format--say YAML.

   But--and here is the crux of my argument--when you've made changes, validation is as simple as:

   perl -c configModule.pm
   [download]

   And if the editor forgets to validate, the error will be detected immediately at program startup, as a Perl syntax error, with the clarity of Perl's syntax error messages.

   Ask yourself:

   How good are the the equivalent error messages for your prospective config file alternative?

   How good is the beta test cycle of your prospective config file format parser (say YAML), compared to that of Perl parser itself?

Many will condemn the existing mechanism as "crude". But crude is often a euphemism for 'simple'. And there is very little wrong with simple.