It's nice that you're willing to share, but a few of them seem counter productive to me.

1. Most of us have jobs that are about getting things done, not specifically about learning. If we have free time once things are done, we can take the time to learn, so code re-use means stuff can get done more quickly, and we can use code that's already been used/tested by at least one other person, reducing the time needed for maintenance ... which may free up time for learning.
2. This may be contradicted by your 'learning' and 'complexity' comments. After all, if you don't write Perl that often, are you going to be as familiar with all of the possible optimizations as someone who does?
3. It depends on the complexity of what it is that you're trying to do. And sometimes it's easier to subclass something to override the output than try to parse it after the fact.
4. I can see part of that argument ... the bigger problem I would think would be those cases where you don't have shell access. (every tried debugging via e-mail? )
5. There was a talk at the DC-Baltimore Perl Workshop last weekend on 'Hooking @INC' that covered how get details of what's required to run something and what still needs to be installed on a given system.
6. If you can't SFTP or SCP a tarball in, you may be able to send it to the sysadmin to place on the machine for it. If you're copy & pasting in each file, something is horribly wrong.
7. A valid argument -- I've worked plenty of places where the production systems had no compilers ... but in every case, there was a development server that did, and you were expected to build there, test, and then push the updates to the production server.
8. If you never do it, you'll never get in the habit of doing it ... once you do it a bit, it's second nature. (or, you just set up templates so you don't have to remember)
9. Might be a valid argument, as I don't know your exact system. But memory *is* cheaper than programming time for anything but trivial work when you start counting overhead (assuming the machine has a slot free).
10. You have to get a review *every* time? Something's wrong with your contract if they can't give you clear guidelines on what you are or aren't allowed to do. (eg, are you selling them the code, which may be a form of distribution, or are you creating the code for them as an employee or contractor?) The only time it's ever been a problem for me (as a contractor) was when the ExtJS folks changed from BSD to LGPL to GPL3, and then gave their interpretation of GPL in which they claimed the backend CGIs that interacted with their code was bound by GPL ... but you make an interesting point. Anyone know of any CPANTS reports that show which modules are GPL3 only and not also releases under a more permissive license?
11. But yet you're paid to learn on the job? I'm guessing that you're like most of us -- you're given the end task and maybe some restrictions in how to implement it You may set some other limitations for whatever reason, but 'being paid to write code' is a flawed argument. If we took it far enough, we could also say that you're cheating by using a high level language like Perl, and not having written your own language.

(and I'm not being paid to post on here, so I'm going to have to reflect that on my timesheet ... blah)