наверно потому что классы, работающие с gui не потокобезопасны (что может следовать также из принципов работы с графикой)

Где-то уже видел ответ на этот вопрос
Насколько я помню, ответ был в том, что с гуем работает человек и так получилось, что за окном приложения может за раз работать только один и выполняться только одно определенное действие: клик мыши, нажатие кнопки и т.п. Поэтому нет смысла создавать многопоточное гуи.
И такая концепция не мешает тому, что у приложения может быть несколько потоков: главное с гуи, остальные что-то делают и посылают уведомления гуи.

Ничего сложного в реализации потокобезопасных классов для GUI нет, изначальная проблема совершенно в другом - в выбранной исходной архитектуре и стратегии обработки GUI событий.
Весь набор GUI в Qt представляет собой связанное дерево элементов, для которого необходимо обеспечить "правильный" порядок обработки GUI событий. То есть, например, прежде чем обработать событие HoverEnter для определенного элемента, для всех предыдущих элементов иерархии должны быть обработаны HoverEnter/HoverMove/HoverLeave. Так же предполагается доступ к родительскому и дочерним элементам во время обработки событий. При асинхронной обработке событий невозможно без сложных правил синхронизации (простые мютексы не гарантируют порядок обработки) обеспечить описанное выше поведение. Отсюда появляется архитектурное ограничение - обработка событий в одном потоке. При этом поток не обязан совсем быть главным! Он определяется лишь местом создания обработчика GUI событий. Например, код ниже работает без всяких проблем.

C++ (Qt)
class Thread : public QThread
{
private:
	int m_argc;
	char ** m_argv;
 
public:
	Thread ( int argc, char ** argv )
	: m_argc( argc )
	, m_argv( argv )
	{
	}
 
protected:
	virtual void run ()
	{
		QApplication app( m_argc, m_argv );
		QWidget widget;
		widget.show();
		app.exec();
	}
};
 
// Начало приложения
int main ( int narg, char ** varg )
{
	Thread thread( narg, varg );
	thread.start();
	thread.wait();
	return 0;
}
 

Необходимо отметить, что сам процесс отображения, например, с помощью OpenGL вполне может быть вынесен в отдельный поток или даже в пул потоков.

Недавно изучал это место. Да, создать UI в "не главной" нитке можно, но будет использоваться другой EventDispatcher. c существенными отличиями.

С OpenGL можно рисовать синхронно, не дожидаясь события ОС. И что, даже из др нитки работает? (не проверял). Если так - то вот и решение, создал QOpenGLWindow и рисую себе из др нитки. Или это утопия? 

Да ответ, я думаю, ещё проще.
Когда разрабатывалось первое UI, никто и не думал, что будет необходимость в многопоточном ui. Да и ресурсы ОС выделялись более бережно.
А так как менять эту систему - значит переписать очень много много кода и ещё больше сил потратить на поддержку устаревших программ, то это никому не надо. Так и живём

Никогда об этом не слышал, всегда железное "только в главной!!!" При случае попробую (ох сомневаюсь все-таки)

В том то и дело, что подготовку данных для финального отображения (где учитывается и порядок, и много чего еще - эффекты, текстуры и т.п.) можно совершенно параллельно, да и обрабатывать события GUI и др. можно независимо от финальной процедуры отображения. И формально только реализованная в Qt стратегия обработки событий накладывает ограничения на принадлежность всего дерева Widget одному и тому же потоку.