Знаете ли вы сколько неудобства есть в программных продуктах, потому что исторически сложилось?
Исходя из современных правил рынка мы не можем долго разрабатывать продукт, полностью его продумывать и описывать разные граничные условия, коих может быть огромное множество, но даже если их все поработать, то есть огромный шанс, что получится не то...
Гибкие методологии как раз и появились для того, чтобы дать короткую петлю обратной связи. Спринт ->релиз ->обратная связь. И все по кругу.
Но тут требуется изначально продумывать гибкий и масштабируемый фундамент.
Что тоже не всегда возможно.
А когда мы получаем обратную связь, то нам, исправляя недочёты и вводя новый функционал, надо ещё позаботиться об обратной совместимости. Вряд ли бы вам понравилось, что при обновлении ПЛК необходимо переписать весь проект, а то он больше не работает.
Для того, чтобы можно было исправить основные недочёты в фундаменте используют обычно мажорные версии или новые линейки оборудования.
Так что если у вас возникнет вопрос, а почему тут так неудобно, то скорее всего-это исторически сложившаяся ситуация, которая держит обратную совместимость, возникшая по причине того, что не было достаточно времени или денег.