Например, есть справочник Менеджеры, пользователи хотят, чтобы Родитель обозначал отдел в котором работает менеджер. В данном случае, про справочник подразделения забудем. На отдел в котором работает менеджер очень много завязано - доступ, расчет цены, возможность по продажам. Т.е руководство рулит через эти отделы
Имхо, для обозначения отдела пользователя использовать отдельный справочник. Или я ошибаюсь?

Какие аргументы в пользу того или иного варинта?

ошибаешься.

Есть документ или регистр связывающий Менеджера и отдел?

(0) Один пользователь может работать в разных отделах.

(3) в разных = в нескольких

Какова глубина? Задаются ли правила на верхние уровни? Может ли пользователь работать в разных отделах?

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

(0)  Какой смысл бороться с пользователями? Хотят, ну сделай. Тебе трудно галочку поставить?

каждый чих - это новая таблица и набор таблиц (сущность).
конечно отдельный справочник.

(0) Все зависит от целей. Если цель не плодить сущности - можно обойтись и одним справочником. Если цель "навешать доп. функционал на подразделения" - значит нужен отдельный справочник.

"пользователи хотят, чтобы Родитель обозначал отдел в котором работает менеджер". Хотелки пользователей учитываются в последнюю очередь. Решать нужно с руководством.

Это роли.

Только у меня возник вопрос? Какая конфигурация?

Вообще у меня есть мнение, что просто иерархических справочников групп и элементов быть не должно

Должен быть не иерархический справочник сущностей со ссылкой Категория на иерархический справочник категорий с иерархией "элементы"

Эта концепция позволит в дальнейшем создавать и мультииерархию

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

(1) аргументы
(2) согласен. В данном случае один менеджер может продавать разный товар из разных отделов
(7) что за глупость? Программист должен делать не то, что хочет польхователь, а то что действительно необходимо
(12) согласен. Но это для большей части пользователей непонятно. Одна мультииерархия чего стоит. А тут все проще с точки зрения пользователя - в папки №1 - значит работает в отделе №1
(13) В том-то и проблема как описать какие будут проблемы при данном решении.

Завязывать что-либо на иерархию - ФУ.

Особенно левые сущности. Потом захочет "менеджер" документ шоб в разрезе отделов движения мутил и т.д. И польется г*внокод рекой.

(0) единственное, чего при такой архитектуре не бывает - это манагеров, работающих в двух отделах.

Ничто не мешает поставить в группу реквизит "Отдел" и назначать его всем элементам, помещаемым в неё.

(0) можно привязать новый реквизит "отдел" к группам справочника пользователей (с автоматическим поддержанием соответствия)

(19) Чтобы при смене родителя автоматически создавался документ о перемещении сотрудника?

надо использовать отдельный справочник "ГруппыПользователей"

(20) ну если "отдел" - это вспомогательный реквизит, то достаточно просто у элемента устанавливать отдел = отдел родителя.

все хорошо, но так и не увидел ответа на вопрос - как убедить пользователя, что иерархия это зло

(23) Не убеждай его. Пусть думает, что оно через иерархию на самом деле работает. (18)(19)(22)

лажа начинается уже в отчетах. Пусть будет тот же справочник Менеджеры, но уже расширенный:
Организация (группа, определяется наличием галки "Организация")
Структурное подразделение (группа, определяется наличием галки "Подразделение")
  Отдел (группа, определяется наличием галки "Отдел")
   Менеджер (сам

потребуется вывести отчет СКД вида:
Организация
Отдел
  Менеджер

и придется писать
Элемент.Родитель.Родитель.Родитель
Элемент.Родитель
  Элемент

т.е привязываться к уровню иерархии.

Можно было бы делать отборами по галкам, но есть фишка, что для вывода ниже стоящего уровня должна (отдел) должна быть галка "Отдел" и у СтруктурногоПодразделения и у Организации

(14) Действительно необходимо только то, что хочет пользователь.