1. It's not a management-imposed thing
TDD was discovered as technique by developers, for their own benefit. Management imposing it can be a bit of an anti-pattern, though it may be well-intentioned. I have certainly pushed teams to TDD, though primarily by example and by the positive experience you quickly get.
Anyway, TDD has nothing to do with management imposition. It is really diametrically opposed, at most orthogonal.
2. "test didn't hit a false positive"
Yes, that's a good thing, though hardly the main point. You write that a careful person does this anyway. I'd rather have a machine do that for me, and have less of a requirement on me to be careful. Computers are much better at being careful, and I want them to do the tedious stuff.
I also am wary of claims of "you just need to be careful". Probably lots of bugs ahead!
3. So why is TDD so great?
First, it's a design technique. Writing the test first forces you to think about how your new production code will be called. It also forces you to be clear about what the code is supposed to do, precisely, before you write the code. Writing the test tends to be significantly less difficult than writing (correct) code to solve the problem. You then write only the minimal code that is required to pass the test, which surprisingly also tends to be fairly trivial. Also, you know when you're done: when the tests are green again.
So you've transformed one difficult step into two fairly trivial steps. Which sounds weirdly magical, but actually works in practice. Also, since you only wrote the minimal code that was required for the tests to pass, you know that you have good test coverage.
After you've done a few, you're in a place to detect duplication and eliminate it by refactoring. This tends to be somewhat more intellectually challenging. However, you are truly refactoring, that is not changing the functionality, so you have a great safety net with the good test coverage you achieved before.
So you get this small steps that are fun and easy, and you tend to not regress.
Psychologically, it's also very pleasant, compared to the usual flow, which goes somewhat as follows:
1. I have a rough understanding of the problem,
2. I code a solution, which is at the limits of my understanding
(because everything is up in the air)
This part feels very good, "I am the master of the universe"
3. Then I should write some tests, but the incentives are a bit negative
-> if the tests all pass, nothing happens, so why did I write the tests?
also if nothing happens, how do I know I actually tested something?
(not by "being careful")
-> if the tests do show a failure, it's a distinct downer from step 2
(and so I probably subconsciously write my test so they don't fail)
4. I don't really want to refactor, because my solution from step 2 was already awesome!
TDD:
1. I write a test. It fails appropriately. That makes me happy.
2. I write minimal code. Tests go green. That also makes me happy.
3. I refactor. The code now is much nicer and tests still green. More happiness.
So with most normal development flows you get that initial rush and then a lot of downers. With TDD, you don't get quite the same initial excitement, but instead you get these nice regular dopamine hits without really much downside.