If you may change your code, you need tests or any change could make a mess and how could you notice? you are gonna waste manually try every scenario of your code to see if something went wrong?, well that my friend is testing, a very inefficient and poorly planned testing but testing, and how will you remember what scenarios to try manually to see if something went wrong? maybe a list? and put it in the documentation? that looks to me as the more time wasting version of an automated test.

Well yes, they do help, but the point I was making is that if you may change your code, that's also the case where the tests may bring a significant time cost in their own maintanence.

If you want someone else to read it, I wouldn't read untested code, because it takes me twice the effort: to understand the code and after to check if actually does it fine, why would I make that extra effort it the original coder didn't do his, making tests?.

But even if it has tests, and they pass, that still doesn't mean it functions correctly. The tests could be wrong.

It sounds like there's another dimension here: from reading "why would I make that extra effort it the original coder didn't do his...?", I'm getting the impression that it's not just about coding philosophy; there's an idea going on here that it's some kind of ethical duty to write tests, that writing code without tests is "irresponsible", even before the argument about whether the tests are pulling their own weight.

Most importantly, automated tests don't replace manual testing, we still have to do thorough manual testing before we ship code (and even still there are often bugs). So I think it's misleading to characterize automated tests as if they are an alternative to manual testing.

At the end of the day, I guess it's not that meaningful a topic to disagree about in the abstract, since (as another commenter pointed out) my question of whether they are "overrated" is too open to interpretation. I appreciate the thoughtful reply though.

I typically look from a business risk lens on whether something is valuable or not to do. Automated end to end tests are expensive to maintain but can provide some level of reassurance the whole flow works for common use cases.
It is more often than not that an engineer is completely removed from the end-user context. The engineer may not know what is important and what is not. Testing provides an engineer a framework to vet whether the changes they made have not broken parts of the system in a location they are not aware of. It could very well justify that the attempt was made instead of just wholly ignored when someone is upset about receiving broken software.