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

КДМне что-то пока сложно сравнить. Могу сказать, что из этих отдельных таблиц можно сотворить поля со списками с динамическим обновлением (научили как), а также строить всякие запросы. Дерево займет много места на форме (по сравнению с 3 ComboBox'ами), да и не научился я пока с деревьями работать.
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком. Когда мы говорим о разработке например клиент-серверного приложения, мы говорим о том, что делаем два независимых взаимодействующих компонента, каждый из которых решает свои задачи. Комбобоксы можно заполнять из разных таблиц и комбобоксы можно заполнять из разных записей одной таблицы. Дерево можно заполнять из одной таблицы и можно заполнять из разных таблиц. Это вопрос реализации клиента и не особо сложный. Более того; в любой момент времени может быть принято решение переделать клиента с комбобоксов на treeview или наоборот, и это никак и никоим образом не должно повлиять на сервер.

КДА по логике вроде бы да, раз в природе эти данные существуют как иерархические, по крайней мере, на карте, то и хранить их надо в одной таблице.
Логика реального мира - опасный инструмент, если пытаться напрямую отразить ее в БД. Допустим, в реальном мире вряд ли существует объект "Пьяный розовый слон". Но может оказаться, что эта виртуальная сущность очень удобна для решения той или иной задачи и она должна быть реализована в БД.

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

Я здесь исхожу из предположения, что задача равно реализуется в обеих схемах, то есть например не может быть неограниченной вложенности в иерархии.

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

Я не очень понимаю, что Вы подразумеваете под противоречием.

Имхо существует единственное принципиальное ограничение - клиент [не привлекая других источников] не может оперировать информацией, отсутствующей в БД. Во всем остальном он свободен; он может взять любую информацию из БД и перекрутить ее как угодно. И исходя из своих задач, таки может именно что перекрутить - например, какой-нибудь OLAP-анализ непосредственно над данными учетной системы.

Разумеется, эта свобода ограничивается практическими потребностями, критерием оптимальности. На макроуровне вполне естественно ожидать определенных соотношений, скажем "модуль клиента - набор таблиц БД", а часто и "форма - таблица". Но с моей точки зрения крайне важно понимать причины и следствия этих соотношений; надо понимать, что это осознанный выбор, который можно и нужно изменить в тех случаях, когда он неудачен.