Если мы по итогам реализации проекта вложились в сроки и бюджет, то реализация лишнего не есть плохо (хотя разработчики конечно могли бы лишний час поспать ).

А доработка этого функционала - это уже возможность заработать денег. Ее можно рассматривать как предложение чего то нового. То есть попробуйте, понравилось - пользуйтесь, хотите чуть подправить  - платите за доработку, не хотите не платите.

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

То что функционал не полный - не факт. Например в модуль бухгалтерии прикрутили месенджер. В принципе бухгалтеру он не нужен, но ему понравилось что удобно скидывать номера накладных или реквизиты своим коллегам. Они не задумывались о подобном,  а тут попробовали и понравилось (Правда непонятно из чего исходил программист прикручивая мессенджер ).

Вот насчет багов проблема, есть баг - негатив ложится на всю систему целиком и не скажешь что "Неиспользуйте вы это не заказывали". Либо убирать, либо исключать.

ТЗ будете актуализировать, если оставляете??

Я вот это и пытаюсь узнать.

Я никогда не сталкивался с подобным.

Мое мнение что ТЗ актуализировать не получится. Как объяснить заказчику, что мы ему что-то "левое" впихнули?

+ По идеи, ТЗ уже давно согласованно и подписано, и как его менять непонятно. Опять же тот или иной функционал должен покрывать задокументированную нужду заказчика\пользователя, а в данном случае заказчик\пользователь никак ее не озвучивает и не факт, что ему оно понравится и уж точно он не готов сразу за это платить.

Так же  при вносе этого функционала в ТЗ мы наживаем "геморой" себе. Получая обязанность "на халяву"  поддерживать и разрабатывать что - то.

В том то и дело
Либо Вы показываете этот ф-ал заказчику и договариваетесь включить это в ТЗ, чтобы можно было поддерживать. Либо по тихому удаляете и все.

Кстати, а у кого - нибудь были в практике подобные случаи ?

Много раз (вызвано особенностью проекта, не спрашивайте почему ). Я написал, что мы делали - скрывали и потом выторговывали или продавали.

Сравнительно небольшие и безобидные дополнительные фичи (как упомянутый выше мессенджер) можно оставлять в качестве бонусов - будет просто полезная дополнительная мелочевка.
Но серьезные излишества однозначно надо удалять. Потом пользователь паче чаяния начнет этими модулями пользоваться, при этом выяснит, что их функционал неполный и несоответствует ожидаемым им требованиям, найдет ошибки, будет скандалить и требовать исправления в рамках сопровождения. Зачем нужен бесплатный геморой?

Ну вот тут момент что он начнет требоваться и захочет дополнения - это не так уж и плохо. Можно попробовать срубить денег на доработке. А вот баги и поддержка это конечно зло.

Что делать если реализованный функционал не описан в требованиях, но не противоречит им ?

Я бы вначале попробовал разобраться в причинах, по которым этот функционал был реализован, но не описан. И уже от этого плясал бы.

На самом деле, я себе вообще слабо представляю подобную ситуацию.

Если не рассматривать вариант когда заказчик напрямую договорился с разработчиками ( в обход всех и вся ), то что должно сподвигнуть программиста выполнить лишнюю работу

На самом деле таких ситуаций может быть огромное количество. Первое, что приходит на ум:

Заказчик передает предварительный запрос на доработку. Доблестный ПМ стартует работы по выполнению этого запроса до подписания официальных документов. Когда все уже реализовано, Заказчик меняет свое решение, отказывается от доработки и не подписывает документы/не оплачивает работы.

Резюмируя обсуждение, принципиальных вопросов, от которых зависят ваши действия два:
1) Вписался ли проект ли в сроки и бюджет? Если да, то функционал - это бонус, и в сопровождение тоже впишется.
2) Считает ли Вы дополнительный функционал настолько ценным, что отдавать без денег - жалко?
После ответа на эти вопросы действия достаточно определены, и в обсуждении варианты звучали.

На самом деле таких ситуаций может быть огромное количество. Первое, что приходит на ум:

Заказчик передает предварительный запрос на доработку. Доблестный ПМ стартует работы по выполнению этого запроса до подписания официальных документов. Когда все уже реализовано, Заказчик меняет свое решение, отказывается от доработки и не подписывает документы/не оплачивает работы.

Ну этот вариант не совсем корректный. Тут речь о другом, о том что все подписано и сделано что - то неизвестное клиенту. Он этого не просил и знает что это. Может понадобится, может нет. Инициатива не от заказчика.

Резюмируя обсуждение, принципиальных вопросов, от которых зависят ваши действия два:
1) Вписался ли проект ли в сроки и бюджет? Если да, то функционал - это бонус, и в сопровождение тоже впишется.
2) Считает ли Вы дополнительный функционал настолько ценным, что отдавать без денег - жалко?
После ответа на эти вопросы действия достаточно определены, и в обсуждении варианты звучали.

1. Сопровождение "левых" фич - это в любом случае дополнительные расходы ресурсов.
2. Вопрос не в его ценности, а в рисках попасть на доп расходы по его поддержки и доработки.

дополнительные затраты - это, конечно, так. НО! ведь на поддержку системы будет новый (другой!) договор, и там можно (нужно!) прописать всё, что вам будет нужно, например адекватную цену.
Сопровождение (= доработка) - отдельная песня, еще один договор со своими условиями и ценой.