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

У меня есть ещё такой вопрос. Как обрабатываются сообщения при завершении программы, а именно после получения WM_QUIT? Если поток посылает синхронизирующее событие после WM_QUIT - что происходит?
1) Сообщение попадает в очередь, поток блокируется, но сообщение не отрабатывается, так как цикл выборки сообщений уже прекратил работу
2) SendMessage выдаёт ошибку, сразу возвращая потоку управление

Я тут столкнулся с тем, что сложно корректно остановить работу потоков внутри компонентов при закрытии программы. Возникла идея, что перед вызовом hiXXXX1234.Destroy компонентов в файле формы вызывать какую-то глобальную функцию типа WaitForTreadsTerminate, размещённую в Share в виде переменной, куда какой-то модуль может прописать свою функцию. Классы потоков добавляют/удаляют себя из глобального списка потоков, а такая функция всем потокам в этом списке подаёт команду "завершить работу".