You seem to be getting a divided opinion. Let me suggest a middle ground. Do not make the suggested changes until you must change the script for any other reason. Then yes, make all the improvements. The benefit of merely changing to pure perl, although real, is probably not worth the effort of validating the new version. If you wait until requirements change, you will already need the validation.

I'm not really sure that's a middle ground, rather it seems to be quite similar to choroba's point. I think the "real answer" is: it depends. Since aartist hasn't shown any real-world examples, we don't know if the code in the backticks is innocuous, or whether it depends on a specific shell (brittle) or puts user input into backticks - a major potential security issue. If I were to receive, for example, some legacy C code and I discovered a buffer overflow, I'd want to fix it sooner rather than later, but of course it could be that there are other mitigating factors, like being able to assume the input this program receives is sanitized. In other words, it should be decided on a case-by-case basis what the priority to change the code should be. As a general response, like in my post, I erred on the side of caution, because in my experience backticks without variables interpolated into them are rare.