I've only spent about 5 minutes looking at it, but so far it looks good.

Politics. Coding practices are always a sensitive area. Although I have used Conway's book as a reference, Perl::Critic is not limited to his rules and will even support contradicting rules. How can we design and represent Perl::Critic to serve the greater-good without alienating people or starting flame wars?

I think the key to not alienating people, is to provide an extremely large set of policies in the main distribution, but only enable a small subset of them by default -- a subset that nearly everyone on the planet can agree on, policies that identify truely risky patterns. This way, when people first try your tool, they don't feel "picked on" the first time they run it against their code base. Let them get comfortable with the system, and discover the plethora of policies they can choose to turn on, and gradually realize "hmmm ... yeah, that is a bad idea.

I haven't delved into your docs enough to know if this is already supported: but having a very easy way to turn on "all policies except the following list: ..." would be another good way to encourage people to use this tool without a lot of work

Examples of policies I think are good, but probably don't need to be on by default...

1. ControlStructures::ProhibitCStyleForLoops
2. CodeLayout::ProhibitParensWithBuiltins
3. CodeLayout::RequireTidyCode
4. ControlStructures::ProhibitCascadingIfElse

...these are all good ideas, but I don't know that I'd consider them dangerous -- let people turn them on manually once they clean up all their bigger problems.

PS: ValuesAndExpressions::ProhibitInterpolationOfLiterals seems to be overly critical. It doesn't seem to much of a stretch to use double-quotes to quote single quotes...

my $t = "can't please anybody";