I think the article is a bit dated because as I read it, this isn't really a unorthodox or new idea at all. This idea is presented as a separate pattern when it really is just a simple Observer implementation. Thinking back to what I was doing at the time, I remember working on logic to sit behind a somewhat complex interface with a number of different panels with data that were interdependent. The user could change values and/or run a optimization routine and based on those actions, events were generated that the UI would listen to and update as needed. There were a number of issues during development where certain panels wouldn't update when they should. The fix (staying within the design) was to generate events from other events. Ultimately, by the time everything was working right, almost every change resulted in all the panels to refresh. All the complexity of trying to isolate when a given panel needed to refresh was for naught. And it didn't matter anyway. It was effectively a premature optimization. I would have saved a ton of time and effort by simply collapsing it all into a single event that refreshed everything.

There are innumerable systems designed in the "fix everything" or refresh everything way. Think of all the CRUD interfaces that add/update a row and then requery the DB. This isn't an exotic approach, it's just the obvious non-clever solution. You have to realize that in 2003, it was the height of 'pattern fever'. From what I could tell, people thought naming new patterns was going to be their path to fame and riches. Don't get me wrong, I think the concept of a pattern is an extremely useful one for describing solutions in the abstract. Things just kind of went off the rails a bit. It's unfortunate because it created a lot of cynicism about the pattern concept in general. It's only in this context that it makes sense to talk about this as an 'unorthodox' solution. It's similar to the orthodoxy around ORMs or DI containers. Not using them is seen as unorthodox even though people had been building software long before these tools existed and in many cases those tools are overkill.

So back to 'fix everything'. A simple example is calculating means. The simple solution is to sum numbers and divide by the cardinality of the values. If you add or modify a number, you just do it again, from the beginning. You could keep track of the sum and the count of numbers and when someone adds a number, you increase the count and add it to the sum. Now you aren't re-adding all the numbers again. If you've ever worked with Excel with a formula that references a range and modified a single value in that range, you have an example of the 'fix everything' pattern i.e. any formula that has a reference to that range will recalculate regardless of whether that value was relevant (e.g. using something like sumif()).

This isn't to say this isn't a smart choice in a given context. In the mean example, lets say we now need to support updates. Now I need to know the old value somehow and only change the sum by the delta. None of this is really that challenging until you consider trying to do this in a distributed or concurrent environment. You now have to handle all kinds of thorny timing issues and you'll likely end up creating a major bottleneck which slows down things far more than recalculating.

The upshot here is that 'fix everything' or 'refresh everything' approach is much easier to get right. You can make a more sophisticated approach work but it's a lot more complicated and therefore more likely to be flawed. In addition in a lot of contexts, the 'refresh everything' approach can be more efficient. For example, copy on write approaches are generally slower for single-threaded approaches but when you have high concurrency, it can allow you to avoid locks and therefore provide better performance. In other cases, it can allow you to batch changes together in an efficient way. So for most problems, you probably want to start with a refresh everything approach unless you have a specific reason why you can't do it and then worry about doing something more complex once you have a need. A working implementation that you can regression test against is valuable in itself, even if it's slow.