Андрей Седышев

Конвертните всё в gettext.
Либо используйте Singleton.

Есть PSR-4, правила автозагрузки следуют ему, работает это все через Composer. У вас же второй Yii, верно?
Модель в папке common\models должна иметь неймспейс common\models.

У вас какой-то гибрид basic и advanced версий Yii2? Откуда при папке common появился неймспейс app?

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

1) Инкапсуляция — мы прячем внутреннее состояние, давая его менять специальными выведенными наружу «рычажками».
• Тесная работа с коммуникационными протоколами (например, почтой).
• Поддержка какой-то вещи с меняющимся состоянием (в вебе этого мало — может, какая-нибудь автоматическая вёрстка?)

2) Абстракция и полиморфизм — в общем, поддержка разных вещей под общим фасадом.
• Неопределённость в технологиях — может, MySQL, а может, SqLite. Тогда создаём абстрактный класс «БД» и от него наследуем MySQL и SqLite.
• Какие-нибудь штуки из предметной отрасли. Пишем игру — персонажей игры удобно так держать. Хотя можно ли написать многопользовательскую игру целиком на PHP — в этом я не уверен.
• Ну, не знаю, где ещё. Настольная/мобильная версия, что ли?

Не забивайте себе голову. Если всё работает и вас всё устраивает, то зачем что-то менять?
Преимущества ООП проявляются при поддержке проекта.
Вы поддерживаете свои проекты? Вы развиваете их? В какой момент вам стало сложно поддерживать проект?
Много ли в проекте абстракций?
Как вы решаете проблему добавления новых абстракций в проект?

Если эти вопросы не про вас, то вам не нужно ООП.

я бы пока не запаривался миграциями.
есть gii, который генерирует модели по таблицам существующей БД.

а миграции, я изменяю таблицы в HeidiSQL, а потом им сформированный ALTER-код добавляю в миграцию (при изменении/добавлении полей).

конечно, есть методы, позволяющие писать меньше sql-кода, но пока можно просто писать ALTER-запросы и выполнять их как sql в теле миграции

Почему появились фреймворки вроде ангуляра?

Помню одно время JS использовался только для всяких там выпадающих меню и попапчиков. Казалось ничего не изменится, пока вдруг не началась ajax-мания. Все вокруг вдруг захотели знать что это такое и как работает. Многие просто начали хотеть себе на сайте ajax, так как без ajax-а уже не по пацански). Примерно в то же время из тени вышел JSON, что только укрепило позиции Ajax на рынке фронтенда (jQuery не будь дураком один из первых запилил чудесный и удобный API для работы с xhr).

Примерно в это же время появились и успешно существовали Full-flash сайты. Которые прилично определи свое время. Уже тогда на флеш-сайтах можно было сделать гораздо больше, чем даже сегодня мы можем с помощью html5, css3 и прочих новых API. Ну и конечно же они отлично умели в XHR. Если бы не сложность разработки и прожорливость флеш-плагина, они вполне могли бы и победить. Но, слава богу, JS тоже нормально научился работать с XHR.

Какое-то время эта технология бурлила, люди методом тыка искали как лучше всего использовать эту технику, пока в какой-то момент кто-то не подумал о том, почему бы весь сайт не сделать на ajax? Сказано сделано. Но к сожалению JS, оказался слишком примитивным языком, full-ajax сайты очень трудно понимать и поддерживать. Ушлые программисты тут же начали писать новые абстракции и сахар для упрощения работы ajax-сайтов. Так появились и начали развиваться библиотеки вроде бэкбона.

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

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

Анджей Ясинский - Ник

не совсем понятна проблема, но в битриксе есть механизм применения шаблонов в зависимости от условий