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

Тесты и не должны покрывать все кейсы кода :) Тесты должны описывать требования к коду.

Под тесты, описывающие поведение, можно написать множество вариантов кода, которые все будут проходить тесты, но валиться на кейсах кода, которые не описаны тестами.

Значть нужно будет проанализировать проблему --> сформулировать новой требование --> написать новые тесты.

В TDD ничто не запрещает иметь коду дополнительное поведение, не покрываемое тестами.

Не запрещает. Так что как ничто не запрещается тебе писать код не обращая внимание на требования :)

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

Это значит, что у тебя проблемы с проектированием софта. Тест тут не виноваты.

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

Никто и не говорит, что тесты - это панацея от чего-либо.