Two erroneous assumptions in your thesis are that 1) unit tests catch all stupid little errors so you can stop worrying about them, and 2) the time spent chasing down stupid little errors that would have been caught by your tests is made up for by the cost of creating those tests in the first place.
Unit tests are not magic fairy dust. Having them does not make your code bug-free and even if something is covered by a test it is still possible that both the test and the code are wrong in the same way. Putting too much belief in correctness due to tests passing can be just as bad as not having any tests at all. Unit tests are great at api boundaries and points of interface between data-munging code, but every function or process does not need its own unit test.
Unit tests also have a high up-front cost that is frequently not justified by the return on this investment. There is a subtle art to selecting the granularity of testing that takes a while to learn, and spending too much time around TDD zealots will often lead coders who have not learned this skill to waste time writing tests instead of getting things done.
Like IDEs that flag type errors, compiler warnings, and debugger breakpoints, a test is just a tool. If you can't write working, maintainable code without any of these tools then perhaps you should spend more time honing your craft instead of collecting another crutch.
Let me share a secret with you: developers are human beings. They make stupid mistakes.
driving defensively is a better approach -- you probably will never need insurance. that's why insurance companies give discounts to those who took defensive-driving course.
This is very true. The only way to learn TDD is to overdo it. You need at least one project (maybe on your own time) where you over-test and find that your unit tests are making the code harder to modify, not easier. It's sort of like inheritance. You have to abuse it to learn that it's best used pretty lightly and obviously.
I knew even before I started that TDD is an aid to design, not a substitute for QA. Still, I got charged up with the idea that my tests were going to cover the entire space of all possible inputs. Bad idea. The resulting pain taught me a lot.