Про спорные решения и откуда они берутся
Довольно часто разработчики придумывают очень неуместные и непонятные технические решения. Я говорю не только о разделении приложения на маленькие модули (зачем это делать, например, в клиенте небольшого интернет-магазина?), а еще и о всяких самописных http-клиентах и базах данных. Безусловно, если проект действительно большой и в его разработке участвуют десятки (если не сотни) программистов, то есть смысл делать специфические для этого продукта решения - они будут решать узкие задачи, и эти задачи уже известны. Но вот если мы пишем маленький или средний (иногда даже и большой) проект, который не имеет расписанного на годы вперед роадмапа, то усложнять приложение в начале его разработки не стоит. Деление на модули не нужно в маленьких проектах, ровным счетом как и куча лишних абстракций. Базовые абстрактные классы и интерфейсы уже создают отличную основу для будущих улучшений, но создание на их основе кучи прослоек только мешает быстрому росту продукта.
Бывает, что такие штуки протискиваются просто потому, что у человека/людей нет другого опыта, он умеет писать только так, и не смотрит/не пытается делать что-то по-другому. Вопрос развития в IT, я считаю, очень спорный, ибо никто не может заставлять тебя развиваться, но в то же время твое развитие очень сильно сказывается на выполняемой работе. Хорошо, если есть коллега, который/которая подскажет, что можно делать, а что лучше поменять. Но если коллег с опытом нет, некому подсказать или провести ревью кода - от компании к компании будет меняться максимум стек, нового опыта в плане насмотренности будет очень мало. Единственный совет в этой ситуации - отнестись к критике с пониманием, через какое-то время вы всему научитесь, это так всегда работает. Не нужно пытаться бежать впереди паровоза - практика всегда требует времени.
Иногда такие вещи проталкиваются людьми просто ради интереса. Захотел строчку в резюме а-ля “Написал собственное решение для хранения данных” - сделал свою БД. Но после ухода это дело будут поддерживать другие разработчики, которые станут задаваться вопросом, почему нужно писать в файл, иметь свои тулы для БД, когда есть уже готовые и проверенные решения? Проблема тут даже больше не в компетентности, а в интересе. Когда у программиста угасает желание развиваться в рамках его текущей компании, но по каким-то причинам он не хочет менять работу, то начинается внедрение всего и вся - от самописных решений до популярных библиотек (если плагин супер-популярный, это не говорит о его высоком КПД, GetX тому пример, но раз он на слуху - почему бы и не попробовать?). Разработчик уйдет (обычно, если люди хотят развиваться, они так и делают), а его творения останутся. У нас на текущем проекте есть примеры фичей, которые не несут в себе ничего, кроме желания как-будто самоутвердиться перед другими, и эти фичи мы либо убираем, либо же ждем глобального рефакторинга отдельной части приложения. Перед написанием собственных реализаций нужно подумать, а что с этим кодом будет в будущем, и насколько вам захочется портить проект ради красивых слов в резюме. Развиваться нужно, никто не спорит, но иногда проще сделать для таких целей пет-проект, а не портить готовый коммерческий продукт.
P.S: не нужно путать это с best practices - их следует применять всегда и в любом проекте. Нужно просто рационально подходить к тому, как разрабатывать приложения и что туда добавлять.