Илья Зябиров

Можно сделать интерфейс для фильтров и реализовывать его для каждого конкретного фильтра. В нем будут методы для получения алиаса (для того, чтобы превратить массив фильтров из запроса в массив классов), установления значения фильтра, а также добавления условия в queryBuilder. Получая из запроса массив фильтров, собираем массив классов, реализующих этот интерфейс (можно, кстати, сделать коллекцию, но это по желанию) и в репозитории проходимся по нему циклом и для каждого элемента вызываем метод, который добавляет условия к текущему queryBuilder'у.

Выше в комментариях вы сами ответили на свой вопрос: используйте CMS. До окружающих вы смогли донести то, чего вы хотите добиться, только написав фразу "наподобие плагинов wordpress". Обосновать же, почему вам необходимо сделать два обособленных модуля в рамках одного проекта, вы не смогли.

Обычно я, при необходимости заполнить БД, использую миграции, где пишу запросы на чистом SQL. Не стоит вызывать EntityManager и тем более протаскивать контейнер целиком в миграции, как писали выше - это плохая практика.
Фикстуры, как здесь уже написали, - тестовая история, хотя никто вам не запрещает их использовать.

Security прекрасно может быть использован в REST, потому что он, по сути, просто предоставляет вам middleware для аутентификации пользователя, запускающееся при каждом запросе к вашему API. Саму же реализацию вы можете как выбрать из готовых, так и написать собственную. А UserProvider в свою очередь предоставляет вам доступ к объекту текущего пользователя внутри вашего кода, что весьма удобно.

Действительно, JWT достаточно, и никто не запрещает вам сделать реализацию без компонента security, однако его использование будет существенно удобнее при использовании этого бандла, который взаимодействует с security. В случае с ним вам не нужно будет даже писать реализацию middleware.