If QCoreApplication::libraryPaths() is called before constructing QApplication, Qt will fail to find the appropriate platform dll in the platforms subdirectory within the application path. This is because libraryPaths() doesn't initialize with the application path if called before QApplication is constructed. While there's a call to appendApplicationPathToLibraryPaths() in QCoreApplication::init() to attempt to remedy this, it's called a few lines too late, as the platform plugins are searched for a few lines above, in QGuiApplicationPrivate::createEventDispatcher().
What makes this bug particularly sneaky is that several places call libraryPaths() internally, so it's not exactly obvious why all of a sudden the platform plugins are not being found. For example, this bug was manifesting for me because I was calling QApplication::setStyle before constructing QApplication (as recommended by the documentation), and the style happened to be unavailable on my platform, so QStyleFactory attempted to use QFactoryLoader to find an appropriate style dll on disk; QFactoryLoader called libraryPaths and made this bug happen. Also sneaky is that this bug will only manifest once the application is deployed: since the installed Qt directory remains in the libraryPaths, this will not be an issue on the development machine.
Maybe the fix is to move initialization of libraryPaths (and the call to appendApplicationPathToLibraryPaths()) in QCoreApplication::init() to before the call to createEventDispatcher()?
Discovery thread: https://qt-project.org/forums/viewthread/41594