Да, это все очень важно. Меня лишь удивило отсутсвие понимание подтекста вопроса о тестах. Ну или не желание на него отвечать прямо в виду невыгодности позиции.
Но давайте подытожим, что я вижу:
1. Тестов либо нет, либо они делаются QA ручками без всяких CI CD. Либо они интеграционные и медленные. И доля интеграционных тестов — большинство. Все это работает и так делать можно. Но если проект у вас не крупный. И даже не средний. Если тесты выполняются руками, то в крупном проекте регрес будет проходить за неделю. Правите в одном месте — опять полный регрес. Если интеграционные тесты — в крупном проекте их тысячи. Должны быть быстрыми для комфортной разработки.
2. Обьем кода от ООП (ОРМ и обвесов) не растет линейно. Т.е. да, вы в начале добавляете 200 строк кода. Но по мере роста вы не добавляете по 200 строк на каждое бизнес-правило. Наоборот. Дополнительный оверхед достигается за счет мапинга, сервисов и репозиториев. Далее вы уже используете готовую инфраструктуру. Отсюда вывод — для маленького проекта не имеет смысла. Дла большого — имеет.
3. Все такпи статичекие переменные — это как раз признак процедурности. Ну или в любом случае затрудненной сопровождаемости кода. Командная работа, поять же сложный и комплексный домен, который невозомжно уместить в голове — все это сразу мимо. И опять — для маленького проекта все окей.
Итого, стиль который вы описали отлично подходит для небольшого по обьему проекта. Со сложным — будут проблемы. Единственное, что тут нужно учесть — это микросервисы. С их приходом каждый конкретный микросервис в целом простой. И там вполне можно так писать. И я бы даже сказал, что иногда нужно так и только так.
Вот такая у меня позиция.