It sounds like you are basing your entire point of view around an experience with someone who didn’t truly understand TDD…
TDD is an amazing practice for all the reasons you’ve probably heard, and it is used a lot in the real world, though probably not as much as people claim, however. TDD does have downsides (like any coding methodology) and the two biggest downsides I’ve seen over the years are a proper understanding of how to use TDD, and a complete team commitment to TDD. Both are necessary for it work in real world dev teams, and both (especially the former) are quite difficult compared to the ‘easy way’ of just coding and guarding with tests afterwards.
In your scenario, it sounds like the feature you were trying to TDD was to large. This is a frequent problem encountered in TDD but the problem isn’t that TDD doesn’t work for real world application, the problem is that the feature is too large to test appropriately and should be broken down further.
TDD helps / forces you to break apart your code in ways you normally take for granted. This is where the clean code aspects and single responsibility principals really start to show because your functions become very small and lightweight, which is a good thing! Bugs and other critical logic become more apparent when you start breaking down your code which enables you to truly test multiple scenarios at the unit level.
TDD takes a while to understand and takes even longer to do properly because it is a very different way of thinking about the design and the way you code.
As much as I tried to refrain from using puns in this response, TDD takes a lot of trial and error to get right! Once you have that ‘ahah’ moment though, you’ll never look at code the same and your developer level will have jump 10 levels!