You can also get a real quick exposure from the Modern::Perl module[1], which is by the author of the book mentioned in a sibling reply.
The basic idea is simple though. Use strict. Use warnings. Use new features and best practices modules (Task::Kensho[2] an help here) when them make sense (e.g. Moose/Moo). Be aware at least what PBP[3] 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.[4]
Not so much out of grace as much as (I think) it's fairly heavy for what it is and somewhat convoluted to configure and use.
Mojolicious and Dancer are the more modern equivalents, and both are frameworks in the vein of Ruby's Sinatra or Rails (probably more in-between). While you can run them as CGI/FastCGI, really nowadays I think most people just run them as standalone pure-Perl web servers (which makes it really easy to access and deal with every part of the request and routing), optionally with a proxying front-end such as Nginx or Apache to speed op static requests or handle SSL (but that's not needed, both are entirely capably of doing SSL encrypted servers in pure-perl with a few configuration params set).
Like the sibling comment, I prefer Mojolicious, and it's simple enough that the landing page for it[1] shows not just one but two fully functional standalone web applications with embedded webservers, one of 5 lines and one of 25 lines (both counts including blank lines). That may not help much with existing Catalyst apps, but I would be hard pressed to recommend Catalyst given how far the state of the art has advanced, but then again I've never really been a Catalyst user, so I may be unaware of a lot of its benefits.
Big monolithic web applications, which catalyst is optimised for have fallen out of favour. Catalyst helped solve many perl tooling problems, and it’s still a totally viable dev target. However as the author of the good catalyst book, I’d probably reach for mojo first in 2018.
The thing I like about catalyst is the same as the thing I like about git. It works well for the smallest use case and it scales well to the largest reasonable case.
In addition to the other comments made here ... Task::Catalyst is right there after Plack and before Template (TT2).
Rather than try to guess at the proper set of modules recommended by a subproject, if there was already a recommendation (ie a Task:: module) we tried to re-use that.
