Apply the YAGNI principle - as long as you have only 3 objects, and only one entry point into your script, you most probably don't need that additional
Application class, so don't create it. This would not make your code more readable or better maintainable - so why bother (for now).
However, when your script becomes bigger in the future, and your
main.pl gets additional responsibilities, it may be a good idea to refactor the instantiation code of those combined operations into a separate function. Giving that function a meaningful name describing the operation as a whole would be very good idea. Furthermore, when your program grows to a state where this operation is just one of many other operations, that would be an even better reason to refactor things out of main.
When it shows up later that this operation needs additional "global" state or environment information, then this new function may be refactored into a class to make that global state a member variable of that class. That class typically won't get the name
Application, since this name is not very descriptive for what the operation does. But refactor when this happens, not beforehand.
AFAIK the notion of having a separate
Application class comes from some (mostly C++) GUI frameworks where this is standard way of definining a kind of entry point and globally available object. See, for example, this SO post, about the
QApplication class in the Qt framework. I don't know if there are Perl frameworks out there with a similar approach, but as long as you are not using or creating such a framework, I don't see a point to add an
Applicationclass to your Perl script.