First of all you argument against exporting is only an argument against exporting functions in @EXPORT or through tags. If you only use @EXPORT_OK, then it is easy to find the imported subs - they are in your use line. Finding said function is very easy to do. Just look at the top of your code before you look for "sub foo".

With the exception of a very few modules that come up so often as to be common knowledge (meaning I make an exception for param() but not much else), I never accept default export lists for exactly that reason.

As for all of your comments about why classes and objects are good, you can do that within procedural code. I should know because I do. Plus a benefit of using procedural code over OO methods is that you are explicit about usage. It can be tricky to track down whether method foo() is in use, and if so, then where the version in this subclass might be called. And if you think you can get rid of it, but are wrong, you won't discover that until you actually exercise the call (by which point you may have forgotten all about that change.) By contrast with exporting functions it is clear which functions are public, and if you try not exporting something you think is unused, you will find that out very quickly when the other module refuses to compile with a message that indicates the broken assumption exactly.

Of course OO has other things it does better than procedural code (I do write both), but for the simple task of controlled access to functionality from one place in another, my experience is that (at least in Perl) procedural is a significant win.