Согласен что хорошо бы сразу думать о будущем. Но есть яркий пример когда это не так - MVP для проверки целесообразности разработки. Тут важнее быстро что-то дать пощупать пользователям, чем закладывать сразу фундамент на долгое и счастливое будущее. В этом вся суть итеративного подхода: бывает надо сделать что-то быстро чтобы работало хоть как-то.

Так что кажется ваш вывод исходит из ложного тезиса: "один из главных приоритетов - поддерживаемость кода", и соответственно может быть как ложью так и правдой.

На плюсах наворачивают такое, что дух захватывает, особенно когда показывают скилом современного и эффективного

дробилки? видимо я не понял о чём речь.

Класс алгоритмов числодробилки: сжатие, шифрование, кодирование и прочая адская математика.

Ну даже если так... Вот допустим делаем мы условный winrar. Мы знаем хороший алгоритм сжатия. Кодим его левой пяткой, но с таймером (чтобы убедиться что сделали его оптимально по времени). А потом выясняется что пользователи вообще-то иногда готовы пожертвовать качеством сжатия в пользу скорости. Иногда условный Вася вообще не хочет ничего сжимать, а просто хочет объединить свои данные в один файл для удобства передачи условному Пете. И вот перед нами уже вопрос: рефакторить эту лапшу или выбросить и переписать заново?

Собственно мой вопрос больше про то, стоит ли изначально жертвовать производительностью в пользу удобства поддержки и развития. На старте любого проекта сложно продумать все мелочи. Но можно "подстелить соломку" на будущее.

Два примера: Windows с каждый раз новым продуктом по сути каждые 4 года и Linux с подсоленной соломкой.