The basic idea is simple though. Use strict. Use warnings. Use new features and best practices modules (Task::Kensho an help here) when them make sense (e.g. Moose/Moo). Be aware at least what PBP is, and if you feel so inclined, use Perl::Tidy and/or Perl::Critic (even if your own defined subset of rules) to give yourself an idea of what is considered good practices (and when to throw them our for that elegant line or two, just don't forget to comment it so you don't confuse yourself when you see it months/years later). Basically, if you care about the code you write, you should find yourself gravitating towards writing Modern Perl anyway, and the speed at which it happens is largely determined by your exposure to the Perl community at large.
My own personal set of best practices means almost always using something like Function::Parameters or Kavorka, and possibly Moops.
Yow, $30+ for the ebook! I wouldn't buy if just for that chapter… fortunately, the guidelines from the book have been codified as Perl::Critic, so If you don't mind missing out on the gently guiding text which accompanies each rule, you can browse the Perl::Critic::Policy::RegularExpressions submodule docs.
Perl 5 has a Tidy'ing tool, as well as a Lint tool. Both are based on rules created from (originally) Best Practices . These rules of course can be modified to taste, so you can set your own rules/filters before checking in your changes to a repo (or, whatever)
Don't focus on the Perl language, just on their best practices for documentation. the guideline in terms of content are totally relevant for any language/developers and polished by practice.
Even if I chose to switch from Perl to python, I still miss Perl in terms of module distribution/testing/documentation.
Perl, and Perl community, I miss you, and I value what you learnt me :)
I advocate for people to be open minded and take good ideas without prejudice on their origins.
Fresh book recommendations delivered straight to your inbox every Thursday.