Рискну с другой стороны подойти к проблеме.

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

   Почему потеря визуальной связи в данном случае никого не смущает? А потому, что нам в процессе проектирования логики нашей программы эта связь абсолютно ни к чему. Тоже самое и с менеджерами - как только мы начинаем их изучать, то нам непременно кажется будто это сложно только потому, что появляется новый тип связи, явно не представленный на схеме и, что самое главное, как и в случае со сплиттером не несущий никакой смысловой нагрузки. В моем понимании "визуализировать" это значит дать возможность наглядно представить процессы, происходящие в схеме. Что наглядно отображает связь скажем интерфейсного элемента с менеджером слоев? Да ничего она не отображает кроме самого факта наличия такой связи. Это тоже самое как протаскивание в электроники проводов питания к каждой микрухе на схеме - ну да действительно без такой визуализации очень сложно понять запитывается микросхема на плате или она там для красоты впаяна...

   Поехали дальше. Откройте один из примеров, насыщенных менеджерами - MRA.sha, WikiCenter.sha и попробуйте четко сформулировать те критерии потери визуальности, которые по вашему там имеются. Только после этого читайте дальше:

1) Оба примера используют TreeViewTrain и MRA_Base в единственном количестве. А это значит, что говорить о потере визуальности между скажем TreeViewTrain и TVT_ChangeNode или между MRA_Base и MRA_Groups совершенно бессмысленно.
2) Откроем пример FormsTreeViewEx_As_DirView.sha - вот вам классическое построение схемы без использования менеджеров, что называется "все в одном". Внимание вопрос: может ли хоть кто-то при беглом осмотре хоть примерно понять чего там происходит? Может быть у кого-то получится хотя бы блоки программы отдельные выделить? Или кто-то скажет, что свои схемы с тем же центральным элементом он делает иначе? Ок, тогда переходим к пункту 3
3) Откроем пример FormsStringTableMTAs_TabGrid.sha - вот вам классический выход из ситуации описанный по пункту 2. Никому ничего не напоминает? Центральный элемент обвешан бреками и вся программа разбита на аккуратные ровные блоки... А по наблюдениям половина новичков большие программы именно так и строит. Т.е. бреки с невнятными названиями для некоторых предпочтительнее стандартных элементов с информативными иконками и что самое главное их использование почему-то не нарушает представлений о визуализации и является более понятным, чем абсолютно такое же связывание через менеджер...

   Вместо итогов: почуствовать преимущества использования данного подхода можно только всецело используя его в своих программах. Так если бы HiAsm был 3D конструктором, то по оси Z мы бы увидели как минимум три слоя - визуальное представление элементов на форме, схему и последний слой менеджеры. Сегодня имея 2D редактор мы не видим связей первого слоя со вторым вообще(кстате замечу, что это никого почему-то не смущает), а второго с третьим видим только через Alt и то не полностью. И именно такая структура присутствует в голове при проектирование схем. Были у нас попытки спресовать первые два слоя - ничего хорошего из этого не вышло, теперь вот есть желание и вторые два слить вместе...