perlcritic is not a straitjacket that compels you to stick, as you say, with it's default settings.

Its manpage is up-front about this:

perlcritic is not limited to enforcing PBP, and it will even support rules that contradict Conway. All rules can easily be configured or disabled to your liking.

.perlcriticrc is your friend. That is where you elect which policies to enforce. Throttle back on those policies just as far as you want -- it won't bite you.

On a serious note, my project at work has swung at the opposite end of the spectrum for years, with some would-be Perl 5.004 programmers who have never used warnings or enforced strict checking, and would never consider taint checking. For them, project and open standards are utterly alien. They have never heard of perlcritic or perltidy. In their laissez-faire freedom, no one has ever shackled them to the constraints of perldoc, Test::More, Kwalitee, make, build, bench-marking, profiling, ptkdb, or any of the other tasty development tools that Perl 5.10 serves up on a plate.

But that lazy freedom has spawned a morass of dud software that enslaves todays programmers who have to learn it and maintain it. There are better ways.

perlcritic is merely a tool that, used wisely, is one element in creating a practical, developer-friendly IDE. Which policies to enforce? Let the project's smartest Perl programmers and architects debate, haggle, horse-trade, and agree on what to choose. Try democracy, not hippy dogma.