Конструктивизм мной приветствуется. Итак, по пунктам:
1. "На практике выборка из таблицы элементов с индексом по IBLOCK_ID очень эффективна. Тесты не показывают хоть какой-то существенной разницы от выборки из отдельных таблиц. Здесь на форуме это уже неоднократное обсуждалось, с цифрами результатов теста."
Это я понял, что идея сделать всё в одной таблице - дань производительности в ущерб традициям релиционных баз данных созданными многими поколениями профессоров американских университетов и защитивших дессертации на эту тему.
2. "Зато в таком способе хранения элементов есть важное преимущество: сквозная выборка из нескольких инфоблоков."
Это приемущество только в том, что за счёт такой архитектуры - сквозная выборка может быть реализована "ленивым кодом". На самом деле нет ни одной задачи, которую нельзя было бы реализовать программно, при любой архитектуре данных, Вы это и сами прекрасно понимаете. Лучше бы вы написали программный код посложнее, нежели нарушили кононы информационной инженерии.
3. "Что касается переноса инфоблоков, то я вас квалифицированно заверяю, что рано или поздно ID элементов хоть в одной таблице, хоть в разных таблицах все равно со временем рассинхронизируются."
Вы имеете ввиду в Битрикс? Да, в Битриксе они рано или поздно - рассинхронизируются, но в классической БД - всё будет неизменным в веках.
4. "Связи между элементами необходимо делать по символьным или внешним кодам, о чем выше уже говорилось."
Это справедливо только для статей, но для форумов нет. Где вы видели, чтобы каждой теме форума давался символьный код? Не бывает такого. Вообще симпольные коды для другого придуманы - чтобы была человекочитаемая ссылка, а не цифровой номер страницы. Вы ещё предлагаете делать внешние коды - а чем тогда эти коды будут отличаться от внутренних ID таблиц? Не легче ли Битрикс вернуться к стандартам баз данных и автоматом создавать всем таблицам свои внутренние ID таблиц? Конечно же легче. Но поезд ушёл, Битрикс уже не может себе позволить признать такой серьёзный недостаток, иначе маркетинговый отдел будет в шоке.
5. "Довод про поисковую оптимизацию несостоятелен, т.к. в рамках одного проекта ID уже не изменяется."
У меня были планы держать инфоблоки одного сайта в разных базах данных, ещё я планировал переносить сайты из одной многосайтовой системы в другую, теперь этому всему не суждено сбыться. Я наверное уйду из Битрикс.
6. "Кроме того, вы можете URL страницы формировать по символьному коду, а не ID."
Повторение мать учения: если всем объектам задавать символьный код, то легче тогда следовать правилу - каждому инфоблоку по внутреннему ID. Дело в том, что у меня сайты, в которых очень много объектов, которые создают рядовые пользователи. Заставить их писать каждому создаваемому ими объекту символьный код - наивно. Писать модуль, который бы автоматически создавал внутреннюю индексацию - унизительно, когда это по традиции есть во всех бесплатных CMS, а я плачу деньги и не имею этого.