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.