Итак,

какие конкретно стоит почитать

1. Макконнелл, "Совершенный код". Объемная но не особо сложная книжка, можно прочитать не особо то за большее время чем такую-же книжку из художественной лит-ры.
2. Роберт Мартин, Идеальный программист. Есть ещё "Программист прагматик", вроде тоже о чем то подобном. Книжка небольшая, в принципе можно за пару тройку недель прочитать рассуждения Дяди Боба о работе программиста.
3 Роберт Мартин, Чистый Код. Весьма хорошая книжка, очень широко затрагивает тему написания поддерживаемого кода. Важно - особенно в этой книге, но так же и в любой другой - не зацикливайтесь на догмах аля "3 строчки на функцию", не обожествляйте SOLID, а рассматривайте, какие проблемы решают предложенные решения. Советую в каждом случае рассуждать о том, как описываемые вещи влияют на качество кода и архитектуры программы.
4. Роберт Мартин, Чистая Архитектура - относительно новая книжка о том, что всё новое это хорошо забытое старое. Возможно вещи описываются немножко поверхностно, впрочем, углубляться в любом случае нужно самому. Книжка годная, получше объясняет SOLID, затрагивает другие принципы, затрагивает парадигмы, принципы дизайна, архитектуру, объясняет почему то, что многие горе-разработчики нынче зовут ООП им не является. Думаю эту книжку можно даже перенести на первое место.
Дальше уж по ситуации - паттерны GoF, PoEAA, Рефакторинг Фаулера, Кента Бека про тестирование etc.

подсознательно я продолжаю выбирать именно "правильные" подходы,

Боюсь, что вы просто используете те подходы что знаете, а не выбираете исходя из требований и ситуации.
Хотя бы потому что "правильных" подходов не бывает, есть подходящие в данной ситуации, и плохо подходящие, компромиссные и откровенно вредные.

наследование — это реализовывается само собой.

Вот эта фраза явно даёт понять что у вас есть проблемы в дизайне. Наследование это весьма опасная штука, и делать его просто потому что показалось удобным, не задумываясь об LSP, контрактах и инвариантах.. Кхм.. Плохо.

Упомяну один момент: статейки в интернете и даже(о боги) на всеми нами любимом хабре или тостере, как и любые другие источники информации, книги и доклады любимых нами авторов представляют исключительно субъективное мнение автора, и лишь его понимание описываемой темы, сформировавшееся в силу, обычно, неизвестных нам обстоятельств. Они могут нести за собой скрытую сложность, абсолютно не подходить в ситуациях отличных от ситуации автора, и никогда не стоит принимать из за единственно-верную истину. Скорее, за пищу для размышлений и альтернативные подходы к какому-либо делу.

Вот вы на Тостер заходите, вопросы создаёте, просматриваете, сайт обновляется, появляются новые фичи, а приходилось ли вам обновлять ваш клиент (браузер) чтобы новыми фичами пользоваться?
Мне не приходилось, нужно лишь страничку обновить, и получить обновленный гипертекст с новыми возможностями для переходов состояния.
Вот вам и HATEOAS, используется часто. Профит - расширяемость, масштабируемость без необходимости обновления клиента.

Благодаря HATEOAS, в частности, мы видим Веб таким, каким он существует сейчас, и с его текущими масштабами.

А если к этому добавить уникальные url'ы, self-descriptive messages, кэширование, не хранить состояние клиента на сервере, использовать известные клиенту и серверу медиа типы можно и REST API получить(есть ещё нюансы)

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

2. Итак, плавно переходим к тому что помнить, вобщем то, нужно будет не только вам. 99% всех библиотек/фреймворков etc. для PHP не пригодны к работе асинхронно.

3. "полностью асинхронным" = отсутствие блокировок? Первое на чем вы споткнетесь - банальные запросы к базе. С дефолтным драйвером они идут синхронно. Точно так же как синхронно работает куча других подключений, и всякие Swoole etc. вынуждены писать над всем этим свои обертки и свои драйвера к БД.

Вобщем, асинк в PHP это огромное усложнение на пустом месте, и при наличии блокирующих операций не имеет никакого смысла. Сильно проще сменить язык программирования, если вам нужна асинхронщина.
По описанию вашего вопроса - гляньте RoadRunner, интересная штука. Как раз чтобы сократить оверхед на инициализацию.
Есть ещё всякие штуки аля https://github.com/php-service-bus/service-bus , но повторюсь, проще подходящий ЯП взять.