|Perl: the Markov chain saw|
Frankly, it just sounds like you're doing it wrong.
mandatory OO design and dependence on modules to perform even simple tasks
I don't consider either of those to be best practices.
you're an OOP elitist who spends the first 30 minutes of every script writing 50 lines of package infrastructure
If it takes you 30 minutes or 50 lines to create boilerplate for a new class, then I think you are certainly doing it wrong.
where everything should be verbose for the sake of clarity
Verbosity doesn't lead to clarity. An obsessive devotion to terseness certainly is unlikely to lead to clarity, usually the opposite. But clarity doesn't require verbosity. And verbosity can certainly go far enough that it interferes with clarity.
constantly have to type out the same one or two-line snippets to handle routine things
That's the opposite of a best practice.
I am not experienced enough to do this comfortably.
Based on what you wrote above, I'd personally encourage you to ease off on worrying about OO, verbosity, and consistency and instead concentrate on trying to write unit tests. Not primarily for the sake of testing (though that will likely prove useful), but to help you see how to do practical abstraction.
Code that can be unit tested well usually ends up being broken into logical subroutines, each with a unified and rather isolated purpose.
I think you need to first concentrate on breaking code up into logical units and get more experience and skill at figuring out how to split code effectively, producing routines with small and clear interfaces and purposes that match their names.
Once you start breaking code into subroutines with simple interfaces (which is called "modularity"), then you'll be able to wrap your head around moving some of those routines into a module.
And if your code is well tested, then you'll build confidence in your ability to refactor things without breaking them.