I have had experience where it helped me personally develop my own skills. I feel it has been a contributor to my improvement and broadening my skills as a programmer.

Implementing it in a business has been a total non-starter, which I believe that this is due to two reasons.

1. The business had no quality control (for code at least) and did no testing.
2. Bad programmers like a certain introspection to self-evaluate themeselves.

As for my first point, a have seen a number of Perl applications that were developed by relatively new programmers. Testing and quality control are something totally foreign to them. In addition, Perl does not have a dedicated project development environment that can walk people through the process.

For comparison, I had recently been using Visual Studio Express from MS. Writing code in the IDE it automatically checks syntax as the programmer writes code. This is the equivalent of running Perl-Critic in an IDE, yet how many editors include that syntax checking directly into the environment?

As for my second point, newer programmers who have no guidance or standards are hard to change. Trying to get a programmer who has figured out something that just 'works' makes them susceptible to a lack of introspection. An inability to self-evaluate their own work. It is from these people that I find that are the most resistant to using Perl-Critic. It is the belief that this tool cannot show them anything new and totally resistant.

I believe that Perl-Critic has a place in every development environment, if nothing else, than from a consistency perspective. It is the lack of consistent tools that I believe is a major holdup to a more full-scale adoption.