Ты сам отличия понимаешь?
1.2.3.Способы 2 и 3 подразумевают, что Ui::MyWidget будет виден всем, кто подключил этот хидер. Первый же способ позволяет использовать шаблон проектирования PIMPL (т.е. подключать UI в cpp файле), что может несколько ускорить компиляцию за счет очень малого замедления работы программы (дополнительная операция разыменования указателя).
Вот и выбирай в зависимости от потребностей. Кстати, никто не мешает тебе потом в конкретном классе менять один способ на другой.

Наиболее удобен в программирования третий вариант - не нужно писать ни myWidget_->, ни myWidget_. перед требуемым полем формы.

Я уже написал, что выгода от использования первого способа - отсутствие необходимости подключать Ui в хидер класса. Что несколько ускорит компиляцию. Еще для библиотек это бывает полезно - вне зависимости от количества аттрибутов класса, оператор new будет всегда выделять одно и тоже количество памяти (например, если изменилась версия библиотеки, то это нужно, чтобы не пересобирать все программы).
А именно с точки зрения удобства программирования лучше третий вариант. Но вот с точки зрения структуризации он не очень - сложней искать концы.

На роль "специалиста" не претендую 
По поводу мн. наследования: это хорошо написано в ++библии, если не путаю называется "Альтернатива: членство или наследование". Предлагается способ проверки: а может ли таких (встраиваемых) быть 2 или больше? Напр. 2 скроллбара - может, значит мн. наследование не подходит.

А если это Qt UI, то указатель - самое ходовое. Объект-член заклинит т.к. Qt parent удаляет child'ов. Мн. наследование - проблемы с "который QObject?".

как показывает практика и как уже написали выше, удобнее всего делать так как это сделано в новосозданных проектах Ui::bdClass ui; при этом наглядно видны контролы, пробовал раз пользоваться третим вариантом, но переделал в итоге обратно на второй, ибо жудко не удобно

Непонятны мне комментарии по поводу видимости контролов, я склонялся к множественному наследованию как раз по причине более простой инициализации начальных значений виджетов и впоследствии доступа к изменённым значениям оных без дополнительного огорода в виде сигналов/слотов и прочих манипуляций... Разве в плане прямого доступа к значениям input-виджетов преимущественнее приватный мембер-указатель в сабклассе? И как я доберусь из него вне класса?
Для ясности вот пример:
Создается диалоговое окно. Его виждетам надо назначить значения, которые до создания диалога не были известны. Без множественного наследования я смогу добраться до виджетов диалога чтобы назначить им значения, а потом получить новые? Ведь мне показалось, что я не смогу напрямую добраться до виджетов, так как они доступны только через приватный указатель и для этого придётся задействовать другие механизмы?

Для таких вещей делаются инлайн методы для доступа к соответствующим подобъектам или свойствам диалога - причем желательно делать константный и неконстантный вариант. Получать доступ к членам класса без функций оберток неправильно. Есть еще куча способов - например сделать мтруктуру с данными для обмена между диалоговым окном и вызывающим кодом а в окне соответствующую ф-ии

C++ (Qt)
setData( CDataForDialog& data );
getData( CDataForDialog& data );
 

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

оба класса зафрендили друг друга, чтобы получать доступ к приватным членам. Интерфейс получает доступ к приватному классу и его членам через указатель, который возвращается макросом Q_D, а приватный класс использует макрос Q_Q, чтобы получить обратный доступ к интерфейсу. То есть они оба содержат в себе по указателю на друг друга. Если взять в пример QLineEdit, то тут вообще сказка получается:

QLineEdit - интерфейс
QLineEditPrivate - приватная реализация

И наследование:

QLineEdit <- QWidget <- QObject
QLineEditPrivate <- QWidgetPrivate <- QObjectData

указатель d_ptr возвращаемый макросом Q_D одновременно указывает сразу на 3 приватных класса
указатель q_ptr возвращаемый макросом Q_Q также одновременно указывает на 3 интерфейса