Just a few comments.

First of all I agree with you on the importance of making your own mind up. I have made similar points in the past, and on several occasions managed to irritate people by refusing to accept the received wisdom. But I think I learn better for it.

That said, there are a few points about your own behaviour that I would like to point out.

• I use strict fairly religiously. While you may not make the mistakes it catches, it catches a good fraction of my typos. Also I note that while you don't use strict, you get most of the benefits (and more!) from the test suites you write. Contrary to appearances, you do attempt sanity and caution.
• Roll your own import or not, decisions, decisions. I have written my own imports before, and most of the time I don't. The rule of thumb that I use is, "If what I want is achievable from the basic Exporter, I use that just so that my semantics will match that. If they are totally different, then I won't. Consistency is good. If I am going to be inconsistent, I have to have an opposing good reason." Generally speaking the more "interesting" the code is, the more likely it is to need custom semantics. The vast majority of code does not.
• I doubt that many knowledgable people would disagree with the uses of typeglobs and symbolic references that I have seen you use. However when you write more routine programs, I suspect you use fewer typeglobs and symbolic references.
• My commenting rules are at Re (tilly) 4 (disagree): Another commenting question,. If you count documentation as commenting (which I am inclined to), then you do indeed have verbose comments.
• I think the key-word about goto is well-placed. Few people know how to place them, and I would prefer to tell people never to use them than to have them try to figure out how to use them well. (An incidental note. Your goto in Switch also uncovered interesting bugs in the development release of Perl...)
• Polymorphism is the one issue I disagree with you on. Sure, 5 people may find 20 ways of thinking about the same problem. But if they are going to work closely together, it is important that they manage to agree on one or two ways of cooperating. Furthermore many of what I consider the worst design mistakes in good modules are attempts to overload functions with every possible behaviour. Take, for instance, CGI's param method. As I pointed out at Re (tilly) 2: form parsing, the overloading is extreme enough that even good programmers will make mistakes and omissions due to forgetting parts of the interface and therefore passing through data that may be misinterpreted as metadata.

  Yes, people find different things intuitive. Yes, people have a native capacity to handle ambiguity. Yes, as long as you stay within the limits of what people can handle, using that native ability is good. Perl has done this very well. But people's intuition is generally flexible enough to learn how your code works, and people ability to handle ambiguity does seem to have a hard upper limit. OK, possibly you don't have an upper limit. But I do, and you manage to exceed it on a fairly regular basis...

Which brings me to my biggest single comment. The average business has a huge concern known as, "What do we do if ___ gets hit by a bus tomorrow?" This is irritating for any decent programmer, we don't want to feel replacable. (Though a tip for bystanders, make yourself replacable and they are freer to put you into new, more interesting, roles.) Well you are not currently coding for a company that can ask that question, but for the sake of Perl, I hope you look both ways before you cross the street...