This argument is not sound at all. The statefulness of your code has nothing to do with why we write unit tests. Even if you write a purely stateless function, it would still be useful to write a unit test to check for correctness. If you are doing TDD, you wrote the test before you wrote the function and that way you know exactly when you are done (because the test now passes). If you wrote your test afterwards, it is still useful if you ever change the behavior of the function, because any unit tests that were written that use this function will now let you know where and in what manner your change has affected the entire code base.

If you are writing bad stateful code that has a lot of bugs and you are not smart enough to figure out how all the states interact, unit tests will help you a lot, but there are many other scenarios where unit testing is useful.

I would not say good code has few unit tests. I say arrogant code has few unit tests. If you write few unit tests, as the size of the codebase grows, you have increasingly less certainty about how any change to the existing codebase will affect other parts. When the codebase is small, this is not a problem. If you are very intelligent, the size of the codebase that you can manage in your head might be quite large. But you are just wasting mental capacity that might have been doing so many more interesting things if you didn't have to remember everything and could trust your unit tests to give you the information you need when you need it.