Hello, utopian.. I wish I could say your crisis is uncommon, but in my personal experience, I've faced a similar challenge...

There are some things that you can do.. not all of these are related to programming Perl, obviously, but have a bearing on your workplace environment (dare I say politics) as well...

Firstly, ask yourself (and your managers) about why you need Perl.. Obviously, there is a situation in which Perl seems to be a good fit to solve a problem.. in that case, you should use Perl to its fullest capacity, or risk reducing it to the level of C or Java or any other language... Most people pick Perl because it has something to offer that not too many other languages do... if you always have to contort Perl to be understandable by a person familiar with another language, you're probably negating the reason for picking Perl in the first place....

Further to this point, -w and use strict, among other things, are part and parcel of the language.. would these people contemplate writing Java without using the class libraries ? of course not... the same situation applies here.. I think that a break with a bad tradition is a good thing, and to support not using these useful language features merely perpetuates bad practices...(I temper this by saying that I share your pain with regard to non strict compliant code... converting all of it hurts.. :o)

The next point, these restrictions may be put in place because no one else in the organization knows Perl yet (and they worry about having another person maintaining your code).. Good code walks and peer review sessions can go a long way towards easing those barriers to entry for a person new to programming (for Perl or any other language)

In answer to your final question, even baby Perl is still Perl... use strict and -w are, after all, merely coding practices that make life simpler and easier for you, the programmer... there is nothing in Perl that prevents you from writing entire production systems without these or any other features... that is one of the good things about Perl, it doesn't dictate the way you should write your code (just try coding any which way you want on Pascal or Modula-2, for example...). If what you want to be doing is writing Perl, then you can still learn a lot, despite these restrictions.. (one of the dumber restrictions I had to deal with earlier was that I couldn't pass a variable number of arguments to a sub.. I always needed to fix the number and have a prototype... just to give one example)..

I have no doubt that once the persons in charge see what is Perl (and you!) are capable of, they'll be willing to give more autonomy in coding practices... Its a hard road, I know... but there are very good reasons for using all the features that you mentioned as being on the no-no list, and with time, it shouldn't be too difficult to convince management of your case...
Good luck..!