Напомните, в чём может быть проблема с запуском QGuiApplication в отдельном потоке?

Но точно помню, что раньше запрещалось запускать QGuiApplication в любом потоке, кроме главного (где функция main). Вопрос: чем может быть это чревато?

ЕМНИП, нельзя сконструировать QThread без существующего QApplication. Поэтому, при использовании только средств Qt, QApplication всегда будет создан (и работать) в главном потоке.

При использовании других средств (std::thread), вроде ничего не мешает создавать QApplication в другом потоке. Остается вопрос с event-loop и сигнало-слотами в не-Qt-шных потоках...

делал такое еще в 4.7-4.8, нормально работает до сих пор, даже под виндой.

Это не будет работать как минимум в OS X - Cocoa предполагает, что используется из главного (первого запущенного) потока. Возможно, простое приложение запустится, но рано или поздно нарветесь на assert в ней.

Есть предположение, что ты подпираешь что-то костылём.. Ответь сначала на вопрос, что тебе даст QApplication в другом потоке?

Возможность использования одновременно несколько разных систем вывода изображения для различных частей приложения, по выбору пользователя: где-то vulkan + sdl, где-то opengl + sdl, где-то qt, где-то gtk, где-то фреймбуффер. Для скорости и эффектов — 3Д графика, для стабильности — qt/gtk. Для этого, работа с ними будет вынесена в отдельные либы, которые будут подгружаться по необходимости, и, в случае ошибок, откатываться на другие либы. Очевидно, нельзя запустить главные циклы каждой из библиотек в одном потоке, поэтому, главного потока, по-любому, кому-то не хватит.

Очевидно, нельзя запустить главные циклы каждой из библиотек в одном потоке

Можно. Qt предоставляет интеграцию чужих событий в свой поток и может выполнять свои события в чужом цикле. Первое делается через QAbstractEventDispatcher/QSocketNotifier, второе через QCoreApplication(QEventLoop)::processEvents.

интресно, сохранил в заметки, но в данном случае не пригодится: либа с qt вообще опциональная