This is not explained any further. I try to find an explanation.
It's something that's inherent to many of us who have debugged massive codebases but you have to deal with a large enough scale at the overseer level for a long enough time to appreciate it. It's like understanding the importance of being in position in Poker. Initially it doesn't seem like such a useful advantage to go last at the end of every turn until you record a hand history of a million hands and realize that you won so much more money in position than out.
That said, I disagree with the idea that a change to a local variable is a side effect. From my view, a function does not cause side effects if it does not modify anything outside of its scope, that anything it touches and tampers with is not going to affect anything below the call stack or any memory or resource the function did not acquire itself.
In general the hardest thing to reason about in a complex, large-scale codebase that doesn't have the most perfect testing procedure imaginable is persistent state management, like all the changes to granular objects in a video game world as you wade through tens of thousands of functions while trying to narrow down among an endless list of suspects which one actually caused a system-wide invariant to be violated ("this should never happen, who did it?"). If nothing is ever changed outside of a function , then it can't possibly cause a central malfunction.
Of course this isn't possible to do in all cases. Any application that updates a database stored on a different machine is, by nature, designed to cause side effects, as well as any application designed to load and write files. But there's a whole lot more we can be doing without side effects in many functions and many programs if, for example, we had a rich library of immutable data structures and embraced this mindset further.
Funnily enough John Carmack has jumped on the LISP and immutability bandwagon in spite of starting in the days of the most micro-tuned C coding. I have found myself doing a similar thing, though I still use C a lot. Such is the nature of pragmatists, I think, who have spent years of debugging and trying to reason about complex, large-scale systems as a whole from an overseer level. Even ones that are surprisingly robust and devoid to a large extent of bugs can still leave you with an uneasy feeling that something wrong is lurking around the corner if there's a lot of complex persistent state being modified among the most complex interconnected graph of function calls among the millions of lines of code. Even if every single interface is tested with a unit test and all pass, there's also the uneasy feeling of what might happen to the central states with an unanticipated input case with all the countlessl interdependent function calls between interfaces if the application's logic revolves around cascading side effects to the most central and persistent states.
In practice I often find functional programming makes it more difficult to comprehend a function. It still spins my brain into twists and knots, especially with complex recursive logic. But all the intellectual overhead associated with figuring out a couple of functions written in a functional language is dwarfed by that of a complex system with persistent states being changed across tens of thousands of functions, where each function that causes side effects adds up to the total complexity of reasoning about the entire system's correctness as a whole.
Note that you don't need a pure functional language to make functions avoid side effects. Local states changed in a function don't count as a side effect, like a
for loop counter variable local to a function doesn't count as a side effect. I even write C code nowadays with the aim of avoiding side effects when possible and have devised myself a library of immutable, thread-safe data structures that can be partially modified while the rest of the data is shallow copied, and it has helped me a great deal to reason about my system's correctness. I strongly disagree with the author in that sense. At least in C and C++ in mission-critical software, a function can be documenting as having no side effects if it doesn't touch anything that could possibly affect the world outside of the function.