"Perl standards" is a bit of an oxymoron - methods/structures/formats/paradigms used depend very much on for/with whom you are working. But, if we appeal to Perl Best Practices (as transcribed on the Perl Best Practices Reference Guide), we find the following relevant points:

192. Make object orientation a choice, not a default.
193. Choose object orientation using appropriate criteria.
223. Export judiciously and, where possible, only by request.

From this, I conclude "it depends". Why do you think it's necessary to have an object class that exports methods? Why do you think it's a good idea to be using objects in your context? Are you taking about exporting by default or just exposing the methods for import (@EXPORT_OK)? If the export question is just about including class/static methods, you can do this simply using package methods (Foo::Bar->method()). If the subroutines you intend to export are general utilities, it likely makes sense to put them in a second, traditional module. You can do what you want (that's some of what makes Perl great), but standards are about code maintenance - will what you do today be obvious to someone else in 6 months time? Mixing paradigms is a good way to move that closer to "no".