Actually your last point was the aspect of this article I liked the most. Most examples I come across of applying non-imperative patterns to fundamentally state

Actually your last point was the aspect of this article I liked the most. Most examples I come across of applying non-imperative patterns to fundamentally stateful applications (UI, games) cheat at the last hurdle. It's usually "we take a model, apply a transformation, creating a new model, and display it - no side effects, we're heroes, now everyone agree to never use imperative languages ever again!" but then forget that they've now created a copy of their entire system, which may cause havoc with anything from memory budgets to publish-subscribe setups or asynchronous update/display loops. At least by not sidestepping this thorny part of the problem the authors are showing a sensible solution which doesn't try to pretend a UI composed from NSViews is a stateless system. Instead they show a reasonable way to maintain its state through diffing it against an idealised model, localising the changes (additions, deletions, updates) to the minimum necessary.