Не совсем. У semibug 2й вариант включает не только поток, но и 
А вот это как раз и не совсем правильно - логику взаимодействия задает основной поток, а реализует эту логику - 2й поток. Более логично было бы отдать и то и другое одному и тому же потоку

Можно и с отдельным потоком сделать полную ж... (*)   
Так что 2й вариант распадается на несколько меньших подвариантов, и их тоже надо тщательно выбирать   

Так никто и не спорит. И в первом случае тоже есть разные варианты обеспечения нормальной работы интерфейса.

Не соглашусь, второму (рабочему) потоку должно быть глубоко по барабану, кто и как его прогресс отображает: может, я в двух окнах хочу это сделать (я, кстати, часто так и делаю). И не надо замусоривать (возможно) сложный алгоритм всякой ерундой типа рисования прогресса. UI - дело основного потока. Насчет того, запрашивать прогресс или пусть поток сообщает - не очень существенно, дело вкуса. 
Я понимаю, что тебе не нравится, что основной поток всякой фигней занимается (по таймеру в основном потоке проверяет завершение выполнение задачи), но это решаемо в смысле дизайна. Я, например, написала  специальный управляющий элемент (панель = прогресс + кнопка Стоп), который как совершенно отдельная сущность легко вставляется в любой диалог и требует буквально пары точек взаимодействия (получает хандл задачи и дальше сам с ней разбирается).

Про отображение речь не шла, речь шла об оповещении, что состояние изменилось.
UI - да, дело основного потока, а вот извлечение информации для отображения нет. Это должен предоставить рабочий поток. UI может вообще не знать, где и как эта информация представлена
Может быть существенно. Данные для отображения генерятся во 2м потоке, и доставлять их проще от источника (и именно в момент генерации) приемнику. Такая система доставки легко и непринужденно ложится на очередь сообщений Windows, и практически ничего за собой не тянет (в смысле объема кода). 
Доставка в противоположном направлении требует синхронизации, защиты разделяемых переменных, и возможно организации callback'ов из основного потока в 2й поток (для запросов) - это явно сложнее, чем один SendMessage
Это совершенно не нужная полумера - или отправлять сообщения 'по течению' (с помощью очереди сообщений Windows), или делать полноразмерную систему MVC. Тут же предлагается подход, удачно сочетающий недостатки обоих систем
Это уже MVC. Чрезвычайно гибкая и мощная система, но требует кода (как минимум того самого 'специальный управляющий элемент')

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

Ну да, конечно, только кода там кот наплакал - идея-то простая. 

В таком случае основной поток должен знать что то о рабочем потоке, в частности где у него лежит этот самый прогресс и как его достать. А это лишние логические связи в программе
Основной поток может выгрести поступающие сообщения, пока они есть в очереди, и только потом обновится
Абсолютно - конечно нет. Но если нет явных предпочтений и UI синхронизируемое обновление не является ПОЛНОСТЬЮ тривиальным, то лучше все же отправлять сообщения от рабочего потока. Ну или полный MVC
Кода не очень много, но он есть. И если нужно засинхронизировать отрисовку ТОЛЬКО прогресс бара и кнопок, то любой дополнительный код вполне может быть излишним