General rule of thumb: If you have @ISA or use base (with use parent being preferred to both of those nowadays) then you should not be using Exporter at all.

ok, but what if I want to allow the user of my New::Class to selectively import methods? in that case I need to use @EXPORT/@EXPORT_OK in order to do so.

Beyond that, exporting sub-routines or variables from a library module (as opposed to an OO package) seems to be considered bad form today (though there could be legitimate reasons to do so in a $work environment.)

You are correct that Exporter is used to allow users to selectively import functions from a module. That said, you don't need to do that with an OO module. The object itself effectively does that when it is called on a method. There is no need to export (or make available for export) an OO method.

There is no need to export a function, though. Any sub-routine in a module can be called directly by means of using the package name, i.e. My::Package::some_function{}. This form of usage is becoming more popular that taking a chance on namespace collisions by exporting some_function().

It is the same with OO packages. A blessed object can call any method defined in the package without it being exported first: $obj->some_function() is effectively making a call to My::Package::some_function( $obj ) (but a blessed object has a few more properties, of course.)

There are things that can be done to essentially hide sub-routines from being available that way, but that is a different topic. :)

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.