1. Думаю что разработчики любой системы считают себя хорошими. Было бы странно, если разработчик скажет, что да, система плохая, кривая и ничего сделать не можем. В таком случае систему проще похоронить, чем заставлять страдать и себя и пользователей.
1.1. Партнеры бывают разные. По своему опыту знаю, партнеры написали какой-нибудь отчет, пользователи начали им пользоваться и резко возросла нагрузка на базу и отчет строится крайне долго. В результате приходится оптимизировать, либо переписывать, либо оставлять как есть. Если оставим как есть, то пользователи будут страдать. Плюс они не знают кто конкретно это делал и считают, что это разработчики плохие.
2. Задачи создаются на основе обращений в техподдержку. Если обращаются по поводу какой-то ошибки, то воспроизводим ошибку и создаем задачу на исправление. Если речь идет об интерфейсе, то часто бывает, что это не ошибка. Просто пользователь забыл что-то заполнить. В этом случае ему объясняется почему система реагирует так, а не иначе. Соответственно кидаться что-то исправлять на основе каких-то "хотелок" по меньшей мере странно. Такое реагирование на обращения в техподдержку используется везде, а не только у нас.
П.С. Когда-то давно лично я не писал. Возможно кто-то другой был.
1. Не важно что думает о себе разработчик, важно, что о нём думают те, кто работает в полях в их системе. Они проголосуют кошельком. Или нет, и им спустили сверху. Не бывает идеальных систем, на кайене можно возить картошку, а кадровый учёт вести в эксельке, но рациональность где-то посередине; 1.1. Гоните в шею таких партнёров, если они даже в теории не имеют понятия работы в команде разработки. Здесь это не раз обсуждалось, в т.ч. и на примере сбора заявок ит-служб. 2. Инструкция, актуальная, версионная. С этим у РМИСов очень туго практически везде, в некоторых регионах на себя это взяли МИАЦы