Alix, По сути ее и нет. 

Ну можешь еще сообщения посылать. Но это изврат какой-то...

Короче, как придумаешь свой уникальный способ - отпишись. Интересно, чего ты там кардинально нового выдумаешь.

Тоже думал на эту тему. Приведу общую постановку проблемы в моём понимании:

• Наша программа занимается вводом-выводом посредствам сокетов.
• Помимо ввода-вывода она занимается какой-то полезной работой. 
• В системах, которых ввод-вывод отнимает достаточно много процессорного времени, для того чтобы не грузить основной поток вопросами IO (InputOutput) мы запускаем дополнительную нить.

Это с точки зрения потоков. Теперь посмотрим на проблему со стороны объектов:

• Есть сущность "Главная форма". Она отвечает за обработку данных, поступивших от IO.
• Есть объект-поток, который и занимается вводом-выводом.

Отсюда следует что как минимум неэстетично грузить поток ввода-вывода задачами обработки, что и происходит в предложенных вариантах (обработчик события выполняется в дополнительном потоке). Это главное что меня смущает в предложенных вариантах, хотя на абслютную правоту не претендую и в ряде задач такой подход может быть вполне оправдан. 
Какие есть альтернативы? Итак, снова начну с общего описания (это решение я нашел вообще в статье про последовательный порт ):

• Мы рассматриваем вопрос взаимодействия потоков.
• Взаимодействие можно организовать посылкой сообщений.
• Можно воспользоваться тем, что потоки выполняются в одном адресном пространстве и для посылки сообщения изменить заранее оговоренную область памяти.

Здесь можно вспомнить о сообщениях windows и использовать их в качестве этой самой "области памяти". т. е. Ваш дополнительный поток просто посылает окну сообщения (виндовыми средствами), а окно их обрабатывает как угодно. 
Теперь к частностям:

• Скажете: "Пример в студию". Отвечу - его у меня нет  Это всё так... Мысли вслух.
• Как избавить код функции потока от постоянных проверок? Очевидное решение - исключения. Чуть что, - raise exception, а в конце метода execute обработка этих исключений с посылкой сообщения окну.

А из этого следует, что ты либо не понял, про что я тебе говорил, либо даже не захотел вникнуть.
То, что я тебе предложил как раз и есть решение того, что ты тут написал (Ну или может быть тут ошибочка ).
Т.к. весь ВВ у тебя будет в твоем дополнительном потоке! Обработку этого ВВ можно включить куда угодно. Хоть в твою форму, хоть в то же поток, хоть еще один поток для него завести.
А форма будет отображать результаты которые даже можно не мониторить а как раз использовать сообщения, что бы уведомить форму о том, что надо бы обновить результаты таких-то операций.

Но это все ИМХО после прочтения твоего ТЗ 

Вы правы, Felan, наши варианты похожи. За той лишь разницей что в моём случае поток ВВ сигнализирует о наступлении события посылкой сообщения, а в вашем состояние объекта-потока периодически проверяется таймером формы. Какой из вариантов применять - дело вкуса. Кстати если задача IO нересурсоёмка, то можно вообще использовать асинхронный ВВ, основанный на сообщениях (если кто не в курсе, то винда сама может уведомлять форму о наступлении события на сокете посылкой сообщения - и не надо никаких дополнительных потоков). (см. Использование сокетов в Delphi. Часть вторая: сокеты Windows, Антон Григорьев, дата публикации 01-10-2004 14:52 или описание функции WSAAsyncSelect в MSDN).