It'd be informative to design better interfaces to such modules. Think to yourself: if I was writing File::Find today, what would I want it to do? In some cases you'll be able to implement your new interface as a wrapper on top of the old module, but I suspect that some things will really require reimplementing the module from scratch.
And obviously the new modules couldn't have the same name as the old ones--they'd have a different interface and so are obviously incompatible with existing code. But there's no law that says people can't install better versions of core modules that are shipped for historical reasons only.
Are some of the modules really this bad? Yes. Take File::Find. It's been somewhat modified lately, but the code in that module used to be in find.pl, shipped with perl4. In fact, File/Find.pm used to be just "require 'find.pl'". find.pl was designed before we had public interfaces. Before we had tie. Before we had objects. Before we had Exporter. Before we had references. Before we gave two monkey nuts about portability. Perhaps, just perhaps, there's a better way to do what it does, or even better things it could do. They might not involve objects and ties and overloaded operators, but they will probably involve a simpler interface and making easy things easy.