Клиентов сильно больше, чем 1-2.

Сами понимаете, больше не скажу. Кто работает, кто финансирует, это посторонним знать не надо. А по обновлениям все просто. Есть системы автоматического контроля версий структуры базы данных. Странно, что Вы про такое не знаете. У меня используется своя разработка. Если кратко, полностью автоматически, без ручного кодирования, генерится отдельный небольшой exe, который актуализирует структуру базы данных. Не последних изменений, а всех, начиная от используемых у клиентов версий. Этот exe запускается после распаковки dll+exe новой версии программы. Или вручную, или в составе процедуры автоматического обновления.
Настройки программы, конечно, есть. Куда без них. Но у нас это макро настройки, включающие или отключающие какие-то режимы. Например, ставим флажок "Работа с Ветис", в меню появляется раздел модуля, в реквизитах фирмы значения для подключения, в справочниках контрагентов и товарах связанные реквизиты. Или включаем флажок "Бухгалтерский учет". Появляется раздел меню, в формах журналов документов и формах документов, где надо, кнопка просмотра проводок. Или включаете режим "Учет упаковок" для работы с разновесом при оптовой торговле замороженными мясопродуктами, в меню появляются пара дополнительных отчетов, а в товарных документах актуализируются реквизиты для работы с упаковками одновременно с весом.
Когда появляется новый клиент, проведение настройки занимает несколько минут. Так как есть четкая логика использования и бизнес профиль клиента известен. Сравните с системой настройки у Вас. Вы выводите в "универсальные таблицы" все, что можно вывести и когда-то кто-то спрашивал, а затем "настройщик" начинает открывать колонки, менять их местами, прописывать формат отображения и т.п. Это совсем разные уровни настройки.
По спинам я смысла не вижу. На мое восприятия, избыточный элемент декора в данном случае. Номера колонок могут быть 3 значными, никто спины жать не будет.
Задача при разработки информационной системы не в том, чтобы сделать минимальное количество окон и контролов. Это из разряда "сделаем всю структуру базы данных на 7 таблицах". Есть и такие проекты. Прописали один раз на все случаи жизни, красота. Те же яйца в профиль. Но люди ведь не зря придумали все эти заморочки с проектированием структуры базы данных, разработкой диалоговых окон, изолированием функций бизнес-логики. Я "гибкими и настраиваемыми программами" переболел еще в 90-е годы. Для меня когда-то было открытием, что в меню программы может быть строка "Приходные накладные". Должно ведь быть "Журналы документов". А там справочник видов документов, заголовки документов и строковые части. Потом уже пришло понимание, что с таким подходом неминуемо снижается функциональность приложения для пользователей. Введение избыточных абстракций ограничивает возможности в развитии проекта, не позволяя углубляться в предметную область и хорошо контролировать бизнес-логику.
Rafael, я не говорю, что у Вас все плохо, у нас все хорошо. Только отмечаю, что системы разного назначения, с разными планками и критериями оценки. То, что работает у Вас, не будет работать у нас. Я же все это не просто так от балды пишу, каждый день анализирую, что можно улучшить в проекте. Но сохраняя его архитектуру и идеологию.
C6/C12, ШВС, tps/btrieve.