When a variable can be reassigned it adds the complexity of time dependence. Meaning that if you don't keep track of the order of values that variable was assigned then you probably can't understand the program. The problem is compounded by the size of the scope that variable exists in. That's why we avoid using global variables, globals force us to track the order of updates from potentially anywhere in the code. The problem is further compounded if there are multiple globals that depends on each other. Then you need to track the relative order of updates across all globals. That's the worst case scenario.
In OOP you try to limit the scope of state, private variables inside an object can update its value but can only be directly accessed from inside the object. But still those objects are inherently stateful. In order to understand an object, how you can use it, whether it is working correctly, you are still forced to understand where/when it is in the timeline of updates.
Purity means that if you understand a variable or object in one place in your code then you understand it from anywhere in your code. You don't need to know how it was used before because it can't be changed. If it were changed then you would know because it would now be a different variable or object.
In OOP you try to limit the scope of state, private variables inside an object can update its value but can only be directly accessed from inside the object. But still those objects are inherently stateful. In order to understand an object, how you can use it, whether it is working correctly, you are still forced to understand where/when it is in the timeline of updates.
Purity means that if you understand a variable or object in one place in your code then you understand it from anywhere in your code. You don't need to know how it was used before because it can't be changed. If it were changed then you would know because it would now be a different variable or object.