В первую очередь нужно решать любую задачу при помощи доступного функционала. Многие даже не представляют возможностей Битрикса и, например, решений от Аспро. И, особенно, молодые специалисты (например по SEO) и новички предлагают делать некоторые вещи, которые можно сделать стандартными средствами, но они этого не знают. И из-за этого вырастают требования на доработки, которые требуют вмешательство в код.
Отсюда вырастает вторая проблема. Доработки, которые делают так называемые "специалисты". Код правится прямо в оригинальных компонентах напрямую, иногда делаются такие костыли, которые потом никто не разберет. И из-за этого при обновлении шаблона все слетает, шаблон перестают обновлять и сайт останавливается во времени.
Если же доработки сделаны правильно, то возникает другая проблема. С обновлениями шаблона вы не получаете обновлений измененных страниц. Например, вы сделали калькулятор рассрочки на странице товара. Следовательно страница с товаром (шаблон компонента детального отображения товара) не получает обновлений. И вскоре, когда копится большое количество доработок, вы аналогично, не получаете обновления для сайта.
А дальше, когда пройдет время, текущий шаблон устареет и выйдет новый, вы захотите перейти на него. Но проблема! Перенос на новый шаблон - довольно затратный процесс. А перенести все доработки - в несколько раз сложнее. И тут вам придется или отказываться от тех доработок или выбирать некоторые или платить огромную сумму за их перенос в новый шаблон. А новый шаблон тоже будет развиваться, причем в начале будет получать очень много обновлений. И снова возникнет вопрос, что вы не сможете их установить и решите что все-таки проще отказаться от тех доработок.
Но зачем тогда их делать? И как решить нужна доработка или нет.
Ответ прост. Ищите способ решения стандартными средствами. Проще немного переделать ТЗ на доработку под функционал, чем функционал под ТЗ. Если нет возможности сделать без доработок (калькулятор рассрочки на странице товара, например), в том случае оценить влияние такой доработки на проект (обновления, возможные переносы и тд) и по итогам принимается решение стоит ли это делать.Клиент платит за доработки, а в будущем заплатит за перенос доработок на другое решение, лишится важных обновлений и берет риски по работе компонентов в будущем при переходе на новый php, mysql и тд.
Поэтому тут все просто. Прикидываете минусы и плюсы. И перекроют ли плюсы все минусы. Если да, делайте доработку. Но делайте их так, чтобы хотя бы раз в полгода или год вы могли обновить этот компонент и перенести туда доработки за пару ctrl+c и ctrl+v.