If you read the book,
you may agree on a certain practice, and therefore use
perlcritic to check that your code is adhering to it.
If you disagree (but you should at least read it before
saying so) you can always disable the checking of that rule
The rationale of the book, and of percritic as well, is to
ensure that a group of programmers use a consistent set of
rules. And "a group of programmers" could be you and the
one maintaining your code 6 months from now, and that could
be you again.
I personally disagree with some of Conway's recommendations,
but I like the principle.
In my defense, I have to argue that Perl::Critic is far from useless. It is simply a source-code analyzer that is similar to the kinds of tools that Java and C(++) have had for years. I used Conway's book as a reference, but Perl::Critic is very customizable and lets you choose the rules you want to follow. And it is extensible so you can easily add new rules that suit your own tastes.
In my organization, we have several Perl developers with different backgrounds and different levels of skill. As a result, a large portion of our maintenance effort is spent dealing with all the idiosyncracies and coding habits of each developer. I wrote Perl::Critc to help level the playing field. By giving every developer a consistent set of rules to follow, we can focus on delivering software instead of struggling with each other's quirks, preferences, and deficencies.
You may not agree with Conway's guidelines, but Perl::Critic doesn't insist that you do. I'm sure you have your own ideas about how to do certain things in Perl. So I invite you to publish your own Perl::Critic::Policy modules and let others benefit from your wisdom.