Что по вашему мнению мешает изначально программистам писать хороший и качественый код?

Поплюсовал людей. А теперь к вашему вопросу, ища аналогии с другим.
Допустим, что мешает производителю производить идеальный продукт, машину и тд?
Как вы знаете, что в начале никогда не получают идеальное решение и все развивается со временем. Если делать идеальные вещи, то потом предприятие банкротится, так как если кто мог это купил и пользуется 20 лет, то за это время производителю тоже что-то хочется есть.
Какое решение для того, чтобы сэкономить время на идеальные машины? Разбивают на блоки, которые можно использовать в разных устройствах. Данные блоки разрабатывают разные отделы, может даже заводы. Таким образом, это модульность, для программистов это тоже так. Уже не говоря о стандартах для каждого, что в программировании тоже бывает.
Так что все идет к тому, что вы уже код не делаете ВООБЩЕ, весь качественный код в библиотеках, а вы собираете как бы из кубиков. Но даже тут, можно из кубиков собрать го в но, особенно если тот, кто делал этот кубик (модуль) сделал его коряво или не идеально под ваши задачи.
Так что же мешает писать идеальный код именно программистам которые пишут модули? Часто время, но самое главное то, что если есть две дороги, то вы идете по той, где нет ям, даже если она длиннее. Поэтому для идеального кода и программирование надо убрать альтернативу написания алгоритма, что делали убирая goto, потом добавляя потоки и тд и тп, все идет к усложнению разработки. Дойдет до того, что никто никогда не будет заставлять писать вас сортировку, а все будет в языке, так как и сейчас есть, что никто не заставляет вам писать функцию извлечения корня операциями, все же привыкли, что есть в библиотеках, так почему не быть библиотекам на всевозможные комбинации алгоритмов?

Недостаточное понимание задач > непродуманная формализация задачи > неоптимальное построение архитектуры софта > ...
Как правило в ТЗ у заказчика описано очень общее представление о готовом продукте. Задача по мере разработки обрастает новыми хотелками, ограничениям и костылями, с которыми приходится мириться. Как правило из экономии времени разработки.
Хорошо формализованные задачи встречаются очень редко. Они исключение
За плохим софтом может стоять короткий срок разработки, когда используется многое "по дефолту" без полировки и работы лобзиком. Функциональность худо-бедно достигнута, а за рюшечки никто платить не хочет
Разрабы давно поняли, что чем раньше продукт появится на рынке, тем больше соберёт урожая. Особенно это актуально для геймдева. Исправить недоделки можно в процессе, а пользователи побудут в роли тестировщиков, им уже не привыкать

Отсутствие полноценной теоретической базы - то самое, регулярно повторяемое на "ответах": "математика программистам не нужна". А без знания математики (разумеется, не школьной пародии, а нормальной вузовской) разработчик не в состоянии оценить качество собственного кода.

Три причины: недостаток квалификации, недостаток времени и сомнения, стоит либо особо стараться, если и так приемлемо работает :)

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

Самая большая проблема это... когда ты забываешь, зачем вообще начал писать этот код. Поэтому пиши побольше комментариев. Особенно шапку. Красивое оформление - это всё!

Да даже если ты сраный гений программирования, может просто не хватать времени сделать нормально - проектирование архитектуры это тоже время, и может не быть выбора как только пожертвовать им и оставить технический долг.

Лень

незнание написания хорошего кода