From your post, I don't think this is the kind of feedback you want, but here it goes. I don't think you have anything wrong in your coding style. In fact, I think you're trying to optimize for mantainability, which cannot be bad.

You're achieving this goal with much more success than what I've seen from many professional programmers, with formal computer science education.

This said, I would suggest you to look into POD for providing your documentation. POD can be stored side by side with your script, so it is very convenient. You can change the code and the POD at the same time. In fact, when I write modules, I tend to write the POD before writing the first line of code. This allows me to think thoroughly in the interface as well as the inner workings of what I need.

If you do your documentation with POD, you can output a very simple usage message or the whole docs with Pod::Usage at your nearest CPAN mirror.

In the efficiency side, I guess this is a very simple example of a data loader. The burden of the work is made by the DB backend and the loader's load is minimal. The only suggestion I could make with regard to this, which does not apply to this specific example, is to only ->prepare the SQL statements that you're actually going to use. It's a waste of resources to do otherwise.

As for the OOP side, OOP is simply a methodology to design your code. Your example, IMHO, is not a nice candidate for generating an OOP solution, as I doubt a significant fraction of it is reusable. You should consider OOP when facing code that can potentially be reused (by you or by others). I find it easier to break down the code in abstract units, not necesarilly tied to the main task you're implementing.