More often than not tests will constrain the architecture of the actual system and result in code that is much more complex than what is required to solve the problem at hand. People then start having blind faith in their tests while being completely oblivious to what they don't test. At that point the codebase is such a mess that you do need tests to maintain it.
People who focus on understanding their code work very, very hard to keep their codebase simple enough to quickly wrap their heads around it. I know I modify my codebase way too much for it to have tests - I'd spend more time refactoring the tests than progressing and I wouldn't be able to simplify the architecture as much because my attention is now on how testable the code is rather than how simple it is.
I see projects shipped with unittests that still required maintenance and debugging 6 months down the road, and others without tests that worked flawlessly out the door.
Of course, there's a difference between understanding and thinking you understand, but that's another matter entirely as we're walking into Dunning-Kruger territory!
I'm not saying tests are bad! Far from it, I do write tests for functions where the logic isn't obvious, but my point is that there's too much focus on testing and not enough on actual quality and simplicity.
Fine grained unit tests are good for helping you find out where a bug is in the code, at the expense of calcifying your architecture. "Functional", "integration", "end-to-end" or other higher level tests don't pinpoint a bug as easily but in return they give you greater freedom to reorganize your implementation.
For example, I work on a code formatter:
https://github.com/dart-lang/dart_style
It has a metric ton of tests, which is absolutely critical for ensuring a change to one corner of the formatting doesn't regress other things. Formatting is solving a bunch of global constraints, so almost every change interacts with other things.
I've rewritten almost the whole thing twice at this point, and the tests never slowed me down. That's because they're functional tests: they just run the formatter and validate the expected output.
It does mean I spent a hell of a lot more time figuring out why some test was failing, but it made refactoring a joy.