I wonder if you are running into the same thing that I have seen with React. Because each node in the React tree is called a "component", people tend to think that it should be self contained. In the article, the author opines that the state should be kept in the same object as the view.
I think this is where people run into problems with React and it is what gets them running for something like Flux early on (I agree that it is not necessary in many cases).
If instead of putting the state for a node in the same node that renders it, you put it in the parent node, suddenly things get a whole lot simpler. To look at it the other way around, a node keeps the state of its children and passes that state as props to the children. That way the children are all idempotent with respect to rendering.
So what do you do when the child wants to update the state? The parent passes a callback to the child and the child calls that callback. This updates the state in the parent and passes new props to the child.
The effect of this is separation of rendering logic from update logic. Every React component knows how to render itself from props. It knows how to request an update to itself with callbacks that are passed as props, but it doesn't know how to update itself. The parent holds the state of the children, but doesn't know how to render them. It simply passes that state to the children. The parent knows how to update the state of the children.
You may recognize this pattern. The parent is the controller for the child. The state that the parent holds is the model for the child. The parent node together with its children form an MVC structure. Of course each child can be a parent too, which leads to a hierarchical MVC structure.
With this, you will usually not need Flux. Of course, one could imagine that passing callbacks is tedious. We could create a special object that handles all the "actions" that the child might make. Then we could simply pass that object in the props. Sometimes, the state that you want to update is several layers up and you end up passing this object down the tree just so that the very bottom node can call "actions" on it. So, instead, we could make this a singleton object and call it a "dispatcher".
Also, you sometimes have situations where, for convenience sake, you might want to store the state in several places in the tree. Let's say every terminal node needs a certain piece of state, so you end up having to put it in the top node in the tree. Then when it changes, you end up rendering the whole tree. So instead, you can create an object (let's call it a "store") that holds the state. Individual nodes observe the "store" and when it changes, they pass the relevant values as props to their children (never updating their own state or rendering it directly!!!). We can even make this "store" get updated by pushes form outside events.
And there you have Flux. Useful in certain circumstances, but I would suggest that if you are finding that you absolutely need it, it's because you are trying to render local state, which you should not do.
With respect to the original article, this is what Windows got wrong (with everyone else, of course). The code that renders the state, holds that state, which makes you reach for WndProc().