I’m not saying tests are bad or that you shouldn’t write test or do code reviews. I’m saying that they are not necessary. […] But try to make a nuanced point about more tests vs. more code to your fellow developers and you’ll be burned at stake and your smoldering carcass will be thrown to wild dogs. Village children will use your severed head to play soccer. (As you can see, I’m a great team player.) And yet I do know that you can write complex, relatively bug free code without tests, because I did it.

The point is not writing complex, relatively bug-free code. It’s about having to change existing code, especially when that code was written by someone else (or your distant-past self).

Similarly, unit tests are also documentation by themselves. Looking at unit tests for libraries is often the best way to find out how to use them, because that is what unit tests do.

And last but not least, the importance of automated tests differs between programming languages.
Anything below 100% test coverage is risky in scripting languages like Python and JavaScript, because even a typo could remain unnoticed until it crashes in production. Integration tests are also much more important, because you can’t rely on the type system to have everything plug nicely together.
On the other hand, in a compiled, statically typed language like C++, Java, Rust, it can be more time-efficient to only have 40–70% test coverage (depending on how good the type system is and what you’re building).