That's one way to do it, tying discoverability to coding convention (which is usually how collocation is enforced), as opposed to being an inherent property of the code.
The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.
Mutating state is actually the de-facto standard across most of the industry. Look at Vue or iOS or Android or Unity or Rails or J2EE... People literally use ORMs to make things more mutable than SQL.
Yes, you can use React setState, but surely it's not lost on you that this is wrapping over a lot of mutable operations too? Worth mentioning as well that setState semantics have some amount of complexity that is attributable to mutability leaking out of the immutability abstraction (e.g. the callback argument, what happens when things like multiple calls to setState occur synchronously, etc). This is the "curse of abstraction" that comes when you are trying to implement semantics that don't exist natively and the abstraction themselves have semantic weaknesses due to the chicken-and-egg problem of the required semantics not existing natively.
I've seen codebases with messy redux and codebases with messy non-redux architectures, and conversely also clean codebases with both types of architecture. There really is no silver bullet technology. The "you can write cobol in any language" thing is always going to be a looming plague.
Given a side effect (a piece of data is mutated), I need to know what code caused it and when. When you casually throw assign statements everywhere that question becomes really hard to answer.