Once this attitude is fully shaped there's no point in using Perl::Critic, since you know what you do, and why, at every step.
Some P::C policies detect code that is undeniably wrong. For years, I recommended the use of UNIVERSAL::can and UNIVERSAL::isa as functions until they bit me in real life. For years, there was no warning on pseudo-static lexical variables (Perl 5.10 added this).
It's not clear that those constructs are always bugs, but they all deserve investigation. P::C can detect those in a large codebase, along with other constructs which we now know to be risky.
Now I don't know what's happened to you and BrowserUK that your hands jerk off the keyboard in shock whenever someone suggests that your team should consider agreeing on the use of a tool that can help you identify things in code that you need to think about, but that's fine. Don't use them. If they give you nightmares or make a bunch of nametags for you that say "Hello My Name Is Winston Smith," then you don't have to use them.
Me, I think they can lead to better code. You'll never see me use the default vanilla set of policies, but you do see me taking advantage of other good tools such as profilers, unit tests, tags, version control, and POD checking tests because I don't trust myself to get everything right the first time. I'm perfectly happy disabling a P::C policy if it doesn't help me write better code, and if the burden of maintaining policy files is greater than the benefit I get from using P::C, I'll throw it out.
I don't see how that means I'm telling coders to turn off their brains and march back into their drab gray cubicles. Frankly, anyone who uses any of these good tools as an excuse not to think and not to do good work has no place on my team.