As Corion already noted, perl runs ActiveState Perl instead of Strawberry on that system. It's a minor red flag (pinkish flag?) for me that 5.6.1 was already at least ten years old when that server was deployed, so I'd take a careful look for any legacy Perl code on that system, to make sure nothing breaks. If you install Strawberry for a single user (rather than system-wide), it's relatively safe, unless of course that user is the one the scripts run as. Then you can fix the paths for Strawberry Perl.

If you run C:\Strawberry\perl\bin\perl.exe -eprint@INC, do you get a more reasonable list? If so, the @INC problem will hopefully stay with the ActiveState install. But if not, it may be a system config issue. In that case, I'd start with an envdump a look at your environment variables to see if any PERL* environment variables have been set, such as PERL5LIB, and if they are, track down where they're being set on your system.

If you're confident you've identified all Perl code on the system (if any), and confirmed it'll run on the latest Strawberry Perl, you can probably get rid of the AS Perl install. It's normally fine to have them both installed, as long as you manage your paths properly, but if it's a broken (and ancient) install anyway, you may be better off without it.