But, 'never say never!':

- it might be that the program in question is restricted to interfacing with a non-portable system anyway

- some modules aren't portable

- the portability of other solutions within the same system may have been addressed in a way incompatible with the perl module.

- (etc.)

Moreover, assuming a module is indeed the best solution for the situation, modular design considerations suggest that you shouldn't plaster it's use all over your application, but rather make your own application as modular as possible by putting your own wrapper module round the usage of the perl module or set of related modules.

For example, instead of using Data::Dumper in every module and main program under the sun, you might consider having one module called MyDebug.pm that uses Data::Dumper and checks a global variable for whether or not your data debugging requirements are enabled.

The biggest benefit of this idea is when you find a requirement has to change, you want to be prepared by such techniques to minimise the modifications, instead of potentially searching and editing throughout an entire source tree.