"Unfortunately, much of this will be a team decision, and I already know that the team is going to want to use perlcritic simply because it will automate some things (yeah, right.) In the meantime, I am looking for tips such as what documentation I really need to look at, and how others have addressed what I think are common problems."

I'd suggest that you get your team to read the first section of the Preface to "Perl Best Practices" and note how many times the words "guidelines" and "suggestions" are used. Ensure they've read the the first sentence of the third paragraph: "This book doesn't doesn't try to offer the one true universal and unequivocal set of best practices.". Show them the publishing date (2005) and make certain they understand this is eight years old.

All too often I've come across statements like "We've got to code it that way because PBP says so." Your team really do need to understand that these are guidelines and suggestions, not rules and regulations. I think once you get that message across, you'll have a much easier time of getting a concensus on a configuration which is useful in that it identifies code which could be improved, as opposed to one that blindly follows every PBP dot-point.

Just so you know, I like a fair bit of the advice in PBP: parts I follow, other parts I don't. I didn't want this to come across as a PBP bashing exercise on my part. :-)