DYLAN

Да тут без холивара не обойтись. И да, это факт. Вы своим большим проектом раздули и так раздутый bitrix.
Безвыходная ситуация - поднимайте ресурсы сервера, и миритесь с диким оверхедом битрикса.

P.S. Adamos Ваш комментарий в точку, выносите в ответ, народ должен знать правду.

Для маркировки кеша компонента тегом зависимости от инфоблока - внутри кушируемой части (блока StartResultCache) вызовите:

$taggedCache = \Bitrix\Main\Application::getInstance()->getTaggedCache();
$taggedCache->registerTag('iblock_id_' . $iblockId);

Возможно Вам и не надо разбираться с роутингом.
Посмотрите в сторону хука template_redirect

Пример

function pan_template_redirect() {
  if ($_GET['my_test']=='hello_world') {
    ...
    exit();
  }
}

CIBlockFormatProperties::DateFormat("d.m.Y", MakeTimeStamp($arResult["DATE_ACTIVE_FROM"], CSite::GetDateFormat()))

Перебить в стилях.

.navbar {
    flex-wrap: nowrap;
}

Тестовые для джуниора:
Какие тестовые проекты стоит написать

Фреймворки:

• Symfony
  
• Laravel
  
• Просто понимание PSR 7 фреймворка (откроет ворота и к Symfony и Laravel и к любому)
  

На CMS смотреть не стоит, разве только если CMS интернет-магазинов (кроме Битрикса — это тупиковые знания, замкнутые сами на себя, и сомнительного качества)

Потому что они связывают на прикладном уровне движка.
Давным давно уже не модно использовать все мыслимые возможности конкретной СУБД.
Хотя бы по той причине, что сие заставляет слишком уж привязываться к конкретной СУБД.

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

Действительно, внутри SQL писать проще. Просто потому, что там решаются гораздо менее глобальные вопросы. Можно сказать, SQL - только примитивных проблем.

Потому вам и проще. Решать примитивные вопросы всегда проще.
По сути вы не проблемы конечного заказчика тем самым решаете - а свои.

В движке ковыряться сложнее, но нужнее - так как там решаются высокоуровневые задачи.
Это не так (то есть можно обойтись одним SQL и не наворачивать ничего в движке) только на простых задачах.

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

Еще одна причина - полноценная реляционная модель со интересующими вас связями плохо ложится на многие прикладные задачи, решаемые на CMS.
Бессвязанные таблицы позволяют делать решение гибче, приближая реляционные СУБД к СУБД No-SQL

Перенос логики из БД в движок позволяет многие задачи решать лучше. Например, такую важную вещь как кэширование. Да и много других.