I don't get how state being evil. Pure functional program also has state. Its state are the arguments passed around between functions.
What people talk about the evilness of state really is the scope of the state. In a typical program, there could be global state in global variable, local state in function local variable, and the state passed around in function parameter. OO adds the instance level scope state for instance variables.
All these different levels of scoping are tools for programmers to manage the complexity in a program. If you don't like global scope, don't use it. If you don't like instance level scope, don't use it. Pure functional code are NOT appropriate 100% of the time. A global variable can be simpler and cleaner to get the job done. There are times for different tricks in a toolset. Use the right tool for the right problem.
edit: added the NOT. Bad omission completely changed the meaning.
State isn't so much evil as it introduces complexity. I think we can agree that complexity, or at least unnecessary complexity, is evil. :) The goal isn't so much to make people stop using state, but to make people think about it and question whether the complexity of state is, in fact, necessary. Maybe the answer is yes! But you should think about it, at least.
To expand on that wrt OO: OO tells you to encapsulate state in objects, generally, and then ignore it b/c abstraction, implementation detail, etc. But state makes it harder to reason about your program because now (ostensibly) the same function gives different answers depending on when you call it, not just how you call it. It couples your program that much more tightly to the order of operations. It introduces a bunch of assumptions dispersed implicitly throughout your code, as everything else now has to ensure that it does the right thing when the order of operations and/or input is correct vs not. That leads to bugs.
The counter-narrative is along the lines of what you suggest, which is to reduce state to a very small and limited scope, and put up a bunch of red flags around it. You say "these answers can change and this is the place to handle all the possibilities." You handle it in as few places as possible, and not laterally, everywhere else a method call chain or where there is state which depends on other state. Haskell is an example of this idea taken to the Nth degree.
But "the right tool for the right problem" isn't that helpful, although I think it's a worthwhile sentiment. The goal is to get people to think about the complexity they add to their programs, not to lambaste them for their choices or take away those choices in the first place.
What people talk about the evilness of state really is the scope of the state. In a typical program, there could be global state in global variable, local state in function local variable, and the state passed around in function parameter. OO adds the instance level scope state for instance variables.
All these different levels of scoping are tools for programmers to manage the complexity in a program. If you don't like global scope, don't use it. If you don't like instance level scope, don't use it. Pure functional code are NOT appropriate 100% of the time. A global variable can be simpler and cleaner to get the job done. There are times for different tricks in a toolset. Use the right tool for the right problem.
edit: added the NOT. Bad omission completely changed the meaning.