The productivity rate went through the roof when we ditched TDD. TDD has a bit of the same problem as strict DDD. You spend a lot of time making upfront decisions about things that does not really matter or you don’t know about.
I see unit tests as a tool to be used where it makes sense and I use it a lot. It is true that testable code is better. Testability should be a factor when selecting tech.
I agree with your first sentence, but TDD and unit tests are completely diametrical concerns.
Unit tests serve multiple purposes. Number 1 is to have a way for you to play around with your design. Then it also can document requirements. I then lastly serves as a vehicle for you to prove something about your design, typically the fulfillment of a requirement, or the handling of some edge case, etc. This last part is what people unfortunately mostly refer to as a test.
TDD says that you should write your tests before you even have a design, one-by-one typically, adding in more functionality and design as you go. You will end up with crap code. If you do not throw the first iteration away then you will commit crappy code.
Most people naturally find that an iterative cycle of design and test code works the best and trying to sell TDD to them is a harmful activity, because it yields no benefits and might actually be a big step backwards.
Unit test has at least three different meanings so I think the term should be scrapped. Here I meant basically automated tests.
I worked with TDD and you basically write twice as much code that is four times as complicated and then you stick with poor design choices cause you have to update all the tests as well.
I see unit tests as a tool to be used where it makes sense and I use it a lot. It is true that testable code is better. Testability should be a factor when selecting tech.