Yes, and no. True, it's impossible to hide what's being run by the "machine" (in this case, the Perl runtime), but what's being run by the machine isn't necessarily what's being maintained by humans.

As a simple example; suppose you have a well written, maintainable program written in awk; but instead of distributing that, you distribute the output of a2p. Assuming a2p works correctly, the resulting program will work identical as the one that was developed, but the cost of the customer to modify the program goes up. I remember playing a text-adventure game somewhere in the late '80s. Getting stuck somewhere, I decided to look at the source code - it was written in C, and I knew C. Except that the game was originally written in Fortran, from Fortran machine translated to Algol, before another compiler compiled it C. Theoretically, I could have found the solution, I had the source. In practice it was quite well hidden; the cost to find it was just too high.

And that's often what the entity requesting "encryption" or "hiding of source" wants. They want to increase the cost of reverse engineering the program. It's the same reason you lock your house; you don't say "well, any lock can be picked, so it's useless to lock my house". Locking increases the cost needed to break in your house, reducing the chance someone breaks in.

Now, in the case of Perl programs, if it's your business model that you should hide the source of your programs, you would have been better off with a different language. I don't know of any tools out there that really hide your source (and with source, I mean the code that's being maintained by the developer, which isn't necessarily the code that's run by the customer). But I'm sure the B:: modules contain enough machinery to write a perl2perl compiler that makes it quite hard to reverse engineer the original source. And don't look at me to help writing such a thing. I don't think you ought to hide your source.