Бывали ли у вас такие случаи, тогда unit тесты не приносили пользы, а только создавали лишнюю нагрузку на разработчиков?

Unit-тесты могут заметно уменьшить при начальную скорость разработки решения, но в дальнейшем они быстрее помогут ловить "баги" и понять, что ты сломал своим новым костылем.

И на досуге, для такого случая лучше нанимать отдельного разработчика-тестеровщика, который будет делать такую обвязку.

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

А так - да. Они замедляют разработку, но позволяют избежать ситуации, когда старый функционал перестает работать.

Любую идею можно довести до абсудра. Особенно, когда речь идет о внутренних компонентах. У меня на практике был такой случай. Нужна была компонента для автоматической расстановки пожарных датчиков в помещении. Подразумевалось, что компонента вызывается из другой программы, которая осуществляет предварительную проверку "разумности" данных. Сами понимате, что само понятие разумности скользкое. Например, помещение в 1000 квардратов - это нормально. Но я застел тестера за очень интелектуальной работой, когда он составлял очет, что программа работает медленно, когда площадь приближается в 10 млн. кв. метров.
Проще говоря, юнит тесты иногда проводятся в абсурдных условиях. В конечном продукте важно отсечь данные на этапе ввода, а не изучать вопросы: "Инетересно, а то получится, если подать идитские данные прямо в расчетный модуль?"
Я в таких случаях говорю: "Интересно, а что будет если засунуть тестеру пальцы в в электророзетку, если все понимают, что это делать нельзя и не разумно это делать?"