I think your goal is laudable. You'll find quite a few discussions on PM about PBP and several that come out generally against some of them. I'd sum up the overall drift as "most of the PBP points are excellent advice and would make the Perl world better and a few really just aren't but all of it is worth thinking about."

We have no standard at my workplace and I've only ever been in one shop that did (via a perltidy hook on commits). Currently we have a handful of solid hackers who have some disagreements about readability issues, etc. We do the "right thing." Don't futz with code style for the sake of your preferences; fit in with what you're working on. Do new stuff how you please with at least some consideration of maintenance for the next sucker hacker.

TheDamian is 10x the hacker I am but some of the advice is subjective and even silly. sub something{ is no better than sub something {. I adore unless and any construct that makes a line of code read naturally (unless(){}else{} is much less natural than do_this unless that). Inside-out objects are a waste of cycles unless you have one of the exceptionally rare real/defined need for them (client code hooks at a bank, for example). Contextual::Return is… a really cool idea and might have some Devel applications but I'm grateful I haven't encountered in a maintenance situation. The book pre-dates Moose.

The main thing I'd argue Perl has going for it versus most other languages for maintenance is its introspection and testing tools. Basic testing with Perl is trivial. Crazy/difficult testing is at least possible. Requiring all new code to be submitted with a peer reviewed test file and to pass a coverage (test and Pod) test and would probably do more for your shop's sanity than a style guide. It is also more objective than a style-guide--which is likely to contain at least a few arbitrary choices for the sake of standardization--so it could go down easier where personal feelings might otherwise cause resistance.

(Update: typo fixed.)