startproger

Абстрактный контроллер реализует Service Subscriber. Вам достаточно туда добавить ваш Setting:

abstract class Controller extends AbstractController
{
    public static function getSubscribedServices()
    {
        return array_merge(parent::getSubscribedServices(), [
            'setting' => Setting::class,
        ]);
    }

    protected function getSetting(): Setting
    {
        return $this->get('setting');
    }
}

По опыту действительно лучше не смешивать, на выходе получается ужас который нужно еще и поддерживать.
Если что сравниваю мешанину с Jquery + PHP или Vue для фронта. Слишком большие проекты не писал, но имея уже текущий опыт могу сказать что это небо и земля. Vue js на фронте чувствует себя прекрасно, ну а данные для рендера берем с бэка по API и парсим json.

Ну в целом вы сами ответили на свой вопрос - React или Vue или их братья меньшие прекрасно справляются с приготовлением фронта. Вопрос в том, какой тип "приложения" вы пишите. React/Vue все еще пока не очень дружат с SEO (сейчас меня закидают тапками, но это мое мнение, я его никому не навязываю), поэтому на них хорошо делать фронт для мобильного приложения или фронт админки/cms/erp и т.п. Для классического веб-сайта (сайт компании, школы, сообщества), которому важно SEO - фронт лучше писАть "по-старинке".

В современном мире действительно стоит разделять backend и frontend. Везде есть свои фреймворки которые стоит использовать для облегчения разработки. Бакенд обычно имеет только api и этого бывает достаточно. А шаблонизатор twig применяют в этом случае для email писем.

Frontend сейчас разнообразен. Это сейчас больше чем CSS+HTML и небольшой функционал на JS. Более того на Frontend сейчас тоже можно делать микросервисы. Одна страница может работать сразу на нескольких JS фреймворках. Например, меню на Vue, а Navbar на ReactJS.

С точки зрения поддержи и развития вы тоже проигрываете. Ведь большой проект требует узких специалистов, в том числе и фронтенд. Если Ваш фронтенд будет на PHP, то на фронтент уже потребуется фул стек разработчик, что дороже и проблематичнее. Значит сложнее масштабирование и развитие. Да и возникают проблемы монорепозитория, куда все изменения с frontend и backend поступают в один репозиторий, без возможности отделения их. Таким образом ко всем разработчикам сразу попадает готовый проект, который легко скопировать и украсть.

Поэтому, если ваш фронт слишком сложный, то его следует отделить. Иначе вам придётся столкнуться с множеством проблем, зависимостью и сложностью как проекта, так и репозитория.

Теперь я использую Doctrine ORM, у которой свойства должны быть закрытыми, а сеттеры/геттеры для таких вещей (которые в базу не заносятся, только контроллер и вид) не надо делать.

Доктрине фиолетово на приватность/открытость ваших свойств, ровно как и на наличие методов для их
записи/чтения, кроме того этого сеттеры/геттеры распространены (абсолютно везде), но все равно это признак плохого кода, писал об этом статью на Хабре: Геттеры/сеттеры и проблема с инкапсуляцией.
А так Доктрина работает с объектами через рефлексию.

Как выводить нужные в другом слое данные, которые нужны для отображения, а не для бизнес-логики — DTO,
отвечал на днях: Что делать, если нужно получить часть данных сущности?

Если хотите работать с полем сущности, но не хотите чтобы оно загружалось из/в БД, то просто не делайте для этого поля аннотацию (или не указывайте его в yml, если используейте его для маппинга):

@Column
Marks an annotated instance variable as "persistent". It has to be inside the instance variables PHP DocBlock comment. Any value hold inside this variable will be saved to and loaded from the database as part of the lifecycle of the instance variables entity-class.
https://www.doctrine-project.org/projects/doctrine...

Итого:
Рекомендую или DTO или сервис (как указал BoShurik), который вернет ссылку, при том в этот сервис можно скормить роутер и создавать сылку не по названию сущности, а по названию роута — это облегчит потом смену сразу всех роутов одного типа, если не меняете название. А вообще и DTO и сервис нужны. В любом случае сущность знать о роутах ничего не должна, тем более этих роутов под одну сущность можеть быть куда больше, чем /blog/ и меняться это может довольно часто...