Бизнес и продажа фичей важнее качества кодовой базы?
Лол. Поздравляю с прозрением. Программист (админ, юрист, whatever) - это всего лишь специально обученная мартышка, а заправляет всем менеджмент. Так было, так есть, и так будет, и топу вообще плевать, что процедурные конструкции оскорбляют нежные чувства какого-то челика, который сегодня тут, а завтра уже нет.

P. S. На всякий случай отвечу отдельно - ответ на вопрос из заголовка: "Да".
Есть такое понятие - "технический долг". Суть в том, что если своевременно не сокращать, по нему могут набежать большие "проценты". Выражаться это может к срыву сроков, большому количеству багов, хрупкости системы и сложности понимания для пользователя, стоимости эксплуатации, выгоранию сотрудников и так далее. Часто бывает необходимо "взять в долг", но так же важно вовремя его "отдавать". Если вы ранее не сталкивались с этим понятием, рекомендую почитать первоисточники.

У менеджмента и продажников всегда присутствует bias в сторону фич, поскольку фича - это то, что можно увидеть и пощупать. С другой стороны, технический долг стороннему наблюдателю оценить невозможно, поэтому он всегда будет сомневаться в том, что технический долг может повлиять на прибыли. Поэтому нередко случается, что технический долг убивает хороший проект. Но происходит это медленно и незаметно, а причины обычно списываются на другой счёт.

Редко можно найти проект с грамотным подходом к управлению техдолгом. Но выход есть, и он - в том, чтобы наиболее авторитетные технические специалисты на проекте планомерно вели разъяснительную работу с теми, кто принимает решения, и в этой коммуникации очень хорошо помогает понятие "технического долга" - особенно, после очередного факапа в продакшене. Некоторые управленцы иногда после этого научаются считаться с мнением технарей. Но могут и послать лесом.