Интересно, почему все доводы за EAV приводят специалисты не по СУБД, а по другим технологиям? Совпадение?

Давайте я лучше приведу такие же плюсы использования одной переменной и одного объекта в программе, написанной на Java или Дельфи?

А то достало уже множество переменных, дурацких классов, пусть всё будет по современному: весь код в одной процедуре с goto, и вместо переменных один массив из строк, в каждый элемент которого можно будет класть то, что надо в данный момент!

Какой я молодец, видите, никогда на Джаве и Дельфи не программировал, и сразу всё понял, как правильно делать! Всё упростил!

Что можно серьёзного сказать про такую идею?
Я вам привёл пример, пообсуждайте его в "Дельфи", серьёзных ответов будет меньше, чем здесь.
Не надо про "все каноны" и "СЦ".
Мы же тут обсуждаем не "все каноны" и "СЦ", а конкретный вопрос, "использование для всех справочников одной таблицы".
Ни в одной ЕРП такого, конечно, нет.
И местные знатоки, считая себя на уровне разработчиков крутых ЕРП, делают так же.

И EAV местные знатоки считают нужным использовать, временами, только не как "вся база в трёх универсальных таблицах", или "универсальная объектная модель", а так же, как это делается в серьёзных системах, для доп атрибутов.

Зачем передергивать ?
Кто говорил про все справочники ?
Речь шла о однотипных минисправочниках из 2-3 полей. В большой системе их могут быть сотни.
Н-р в 1С это называется перечисления.Ну, из поста ТС точно непонятно, что имеется в виду.

И в 1С, уверен, нельзя будет занести в поле "цвет" значение "твёрдый".

В 1С это не "одна табличка", а некая система "перечисления", которая устанавливает перечень допустимых значений и т.п. С кучей метаданных, интерфейсными формами, отчётами для администратора и т.д.
А сделано так потому, что в 1С свой язык, по сути, своя РСУБД, которая есть надстройка над ядерной РСУБД.

То есть в системе уровня SAP, 1C, SharePoint, MS, Excxange такое можно понять. Притом не для всех справочников, по критерию "в которых мало записей", а в определённых бизнес-справочниках, что тоже большая разница.

А вот в системе ,в которой 30-100 справочников, нет своего ЯП, своего дизайнера, которая не является "конструктором", всего этого не надо.
Либо лишнее усложнение и удорожание, либо сделанная "для галочки" одна "таблица-справочник", которая, кроме удорожания кода, ничего не принесёт)

Если беку писать новый метод для заполнения каждого такого выпадающего списка в случае одного справочника, то никакой экономии не будет.

Проблема в данном случае не в недостатках отдельных справочников, а в программной архитектуре (API) бэка.

А зачем писать, если можно не писать ? Заполнение и импорт всех справочников происходит в одной форме, которая принимает в качестве вх.параметра лишь имя конкретного справочника. Причем это прекрасно ложится на нативный SQL.
Именно в этом и фишка - сделать один несложный код для всех.А зачем каждый раз писать новый метод, для справочников в отдельных таблицах?
Разные таблицы, или одна - это просто чуть разные метаданные, не более.
Сервер хранит имя таблицы, или вы сами - не надо, что бы от этого зависело количество методов в классах.

Вот, честный ответ: быстро, дешево и сердито.Да тут и скорость программирования ни при чём.
Ребята пишут горы безумного ненужного кода на каждую новую таблицу, ибо "так надо", "все так делают".
Но если таблица будет виртуальная. самопальная, то почему то уже "так не надо", потому то уже не нужно делать на каждую строку большого справочника свой метод.
То есть если используется серверные метаданные sys.tables, то по фэн-шую надо сделать в дата-слое класс для каждой таблички, а вот если своя васяпупкин.tables, то почему то вдруг не надо, по тому же фен-шую. Очень странно.
Вот не надо делать для каждого из одинаковых справочников новый дата класс, DAL-класс и т.д.
Нужно для справочников вида выпадающий список делать один класс, и передавать в него имя таблицы.

ИМХО, это у обсуждаемой теме отношения не имеет.
Мы же не говорим про "простокод", когда на таблицы автоматом генерятся дата-классы, а запросы сам составляет фреймфорк?
Есть модель БД, есть архитектура, модель, сервера приложений, и есть модель клиентского приложения, и это три разные модели, а не одна. Притом для одной базы может быть несколько серверов приложений, и ещё больше приложений, да и баз, собственно, тоже может быть много, в общем случае.

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