Reverse that thought: As long as there is someone to blame (read: payed support for the software), then it's OK to use it. So if Core Perl comes with AIX, backed by IBM or Core Perl comes with RedHat, backed by RedHat, or Core Perl comes with Windows, backed by ActiveState. then it's OK to use it.

Mitel (they do IP phones for businesses), for example, has their core management software written in Perl (robust), all tools around it are written in more modern languages (Java) and interface to it.

I've seen one case in the wild, where they had this specific, certified Perl version, in a separate directory to run a program that connected to a database. It broke when the new OS C libraries were not supported anymore (Perl binds to C for low-level things). Instead of rolling back the OS (because the security team pushed those changes, these are not reversible) the software was abandoned (due to too little time/knowledge to fix it and a management decision to replace it) (yes, probably an update in the hashbangs and a re-download of the relevant CPAN would have fixed it - but we did not get authorization to download from CPAN)

As for trusting your encryption code. No. You will need to seek 3rd party certification for that, unless you are a big company with a name already. The certification, of course, is on top of your fuzzing, Robustness testing and your weekly/monthly? report of your TestDrivenDesign test-suit against a freshly patched OS (and maybe even the customer's flavour of Patches). It's lots of work, unless automated, to certify that a CVE patch will not break your software... and that means testing each individually, or as a group.

If I put on my Managers hat, then I would trust a leaky Java, DotNet, $flashyLanguage E2E-encryption software more than a Perl E2E-encryption software. Don't tout that it's Perl on the first page. Perl is not sexy at the moment. Old and Stable is not a selling point. But having Ansible checks the CRC's and certify that your software is still "original and unchanged" is... and it's auditable.

Also note that because there are less eyeballs on a language, the amount of bugs found is less. While weird experimental stuff is still added to it...

As for hacking your system. Depending on how important it gets, maybe nobody will care to hack it. However, read up on SoftICE (sorry my age is showing) and strace and man-in-the-middle.

This year I played with a certain tsocks/toxsocks encryption. I bound to their compiled libraries and got their password encryptor/decryptor working, because it was modular, and small.

So instead of embeddable E2E and selling only the software I would go for total solution, and also sell the hardware. Don't use R-Pi's (not even for a show-case) but only use expensive and certified hardware (a good NUC, for example)! And if you go for software only, maybe go opensouce, like PGP and sell certified solutions with it.

Anyway, good luck with your journey deciding for Perl!