И если я захочу заюзать стандартный параметр FILTER_NAME - то я не смогу применять в своих выборках эти данные.
Например, тут всегда выбираются только элементы, активные по дате, но это жутко неудобно. Например, у меня есть инфоблок "Выставки", и у выставки обычно есть поля "Начало выставки" и "Окончание выставки", очень удобно использовать для этого уже встроенные DATE_ACTIVE_FROM и DATE_ACTIVE_TO, но если я потом захочу вывести с помощью компонента bitrix:catalog.section или bitrix:catalog.top список будущих выставок (начало активности которых еще не наступило), то так не получится.
Прийдется создавать два свойства с типом "Дата" (начало и конец выставки), и потом по ним уже фильтровать, что дольше, и ниже по производительности (выборка по связанной таблице).
Создавать свой компонент catalog.section и выносить в отедльное пространство имен не хочу, так как стандартные компоненты круче.
Но если разработчики Битрикса смилятся и добавят в стандартные компоненты больше проверок:
Выносить их в настройки компонента (и загромождать форму редактирования) не нужно, достаточно только чтобы они были в самом компоненте, если нужно - разработчик будет их использовать и передавать в компонент, главное только чтобы это было предусмотрено в стандартном компоненте.
Количество кода практически такое-же, вроде бы никому такие параметры не мешают, логику никакую менять не нужно, как работало так и будет работать, если параметр не задан - пишет "Y" (как и было до этого), а если задан - то можно его менять.
Почему бы не добавить? Это же реально 5 минут дела, зато тонны сэкономленного времени разработчиков, причем всех, кто пишет на Битриксе на стандартных компонентах.
Такое впечатление, что это сделано преднамеренно и такой тотальный игнор связан с каким-то определенным умыслом.