Вячеслав Шевченко

Называется, услышал звон, да не знаю где он.

1. Сервисный слой ты превратил в контроллер.
Т.е. у тебя есть контроллер, а ты создал ещё один, т.к. где-то слышал, что нужны сервисы.
Но, сервисы не шлют ответы, это внутренний слой для отделения логики.
Ты можешь те методы вызвать через консоль, другие сервисы и т.п.
Там должен просто генерироваться return, а сам response уже в контроллере (чтоб контроллер своб функцию выполнял). Валидацию реквеста кстати тоже надо делать не в сервесе.

2. CategoryQuery - это вобще дичь дикая.
Ты опять создаёшь дубликат, потому что услышал о репозиториях, и даже интерфейс. Вот я угараю с людей, кто везде пихает интерфейсы. Интерфейсы нужны там, где они нужны. Где будет 2+ наследователей интерфейса.
Откуда у тебя тут наследники, если ты завязан на элокуент?
А ноги от индусов репозитаристов. Не нужен репозитарий, Query и интерфейсы при работе в элокуент. Он сам в себе это всё уже содержит и все повторяющиеся вещи обёрнуты уже. find, first, firstOrNew и т.д.
Так что используй элокуент и не переусложняй проект напрасно. Не надо делать сложно, делай просто.

3. CategoryAction.
Опять интерфейс...
Вот это Экшн по сути у тебя сервис. Тут ты имеено перенёс бизнес логику создания и редактирования и возвращаешь ответ данного метода. Вот удали свой CategoryAction и перенеси методы в сервис.

ставьте на счетчик его

тут проблема что неизвестна Ваша архитектура, в том числе предобработка запросов, так что гадать много можно

счетчик, логи, увидите закономерность

В ядре убрана возможность использовать операции добавления/удаления/обновления для элементов ИБ (таблица \Bitrix\Iblock\ElementTable) через ядро D7. При обновлении элемента ИБ нужно довольно много данных в других таблицах менять (поисковые индексы, фасеты и т.д.). Поэтому в коде bitrix/modules/iblock/lib/element.php можно увидеть такое :

public static function add(array $data)
	{
		$result = new ORM\Data\AddResult();
		$result->addError(new ORM\EntityError(
			Loc::getMessage('ELEMENT_ENTITY_MESS_ADD_BLOCKED')
		));
		return $result;
	}

public static function update($primary, array $data)
	{
		$result = new ORM\Data\UpdateResult();
		$result->addError(new ORM\EntityError(
			Loc::getMessage('ELEMENT_ENTITY_MESS_UPDATE_BLOCKED')
		));
		return $result;
	}

	public static function delete($primary)
	{
		$result = new ORM\Data\DeleteResult();
		$result->addError(new ORM\EntityError(
			Loc::getMessage('ELEMENT_ENTITY_MESS_DELETE_BLOCKED')
		));
		return $result;
	}

В документации на метод прямо указано:

Метод заблокирован. Используйте метод CIBlockElement::Update

Если хочется держать фронтенд в тонусе - то лучше использовать пару пакетов с компосера, скажем роутер и шаблонизатор прикрепить. Вынести логику в контроллеры ,а в контроллерах использовать Bitrix api.
Ларавель слишком громоздок для этого - т.к. битрикс на бэкенде уже все делает, а из ларавеля вы будете использовать только шаблоны роутер и контроллеры. Если не хочется самому выбирать пакеты то можно посмотреть в сторону микрофреймворков, к примеру люмен.

Я как человек проработавший лет исключительно с битриксом понимаю желание скрестить слона( неповоротливый Битрикс но с кучей, громадной кучей готового функционала, начина от простых списков, заканчивая многоскладовым ИМ с бек джеком и куртизантками) с гипардом( быстрый фреймворк с кучей прелестей, но всё приходится проделывать вручную). Но делать всё таки этого не стоит. Т.к. потеряете хорошую часть функционала битрикса - такие как: быстрые правки, индексация сайта и сайтмэп, компонентный подход и помощь если запутаетесь в своём творении. Если хочется красивых шаблонов компонентов - битрикс поддерживает сторонние движки шаблонизации, а что касается шаблона сайта - тут боль только php... Ну а если вам хочется своих компонентов с наследованием - тоже можно реализовать.

Я на последнем проекте своём написал порядка 20 компонентов под нужны проекта без кучи грязи в и лаши которая постоянно наблюдается в стандартных.

В поле thumbnail_id в любом случае будет лежать одно изображение, но вы можете создать дополнительные, визуальные мета-поля с помощью популярных плагинов ACF/CF

Насколько оправдано хранить информацию о файлах в базе данных

Если судить с колокольни разработки веб сайта c, то оправдано. У вас будет сущность, которая будет уметь работать с этими файлами, правилно их выводить, сохранять в различные файловые системы (s3, локально etc.). Прокидовать их через прокси, что бы вешать водяной знак, знатьк какой повесить. Настройки прав доступа для юзера.Быстрый подсчет количества файлов, методанных.

А вот минусов в таком подходе я лично не вижу

Битриксоид до мозга и костей

и такой вопрос?! .. кхм..

хранить информацию о файлах в базе данных

это фичи ФС по тому и ответ простой - если вам требуются возможности, которые ФС не способна предоставить* - это нормально. в противном случае - такое решение избыточно, и может быть лишним источником ошибок

upd * включая скорость отклика, если на то пошло

Конечно, оправданно. Некоторые даже и сами файлы норовят в БД запихнуть :) . А если с практической точки зрения, то вы можете использовать алиасы для файлов, прочую сопутствующую информацию сохранять, управлять правами доступа к файлам И так далее...

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

Другие проекты поступают так, как требуется в их конкретном случае.
Если никакой дополнительной информации о файле хранить не требуется, то и в бд их пихать не нужно.
Если файл встраивается в БД - например, может относиться к сразу нескльким категориям, то без БД просто не обойтись, и таких вопросов в принципе не возникает.

есть еще такой вариант:
при загрузке файла, он компилируется в small medium full и сохраняется original
в базе имея один id ты имеешь 4 файла, которые можно использовать например для адаптивности, или вывода preview или detail, а также 3 вида минимизируются для уменьшения объема трафика

1) Иногда бывают API
2) Чаще всего используют RSS-ленты
3) Иногда парсят HTML

К каждому источнику данных есть свои подступы.