A lot of modern programmers are stuck at the same types of dumb problems over and over because library / app designers (even the famous ones) often don't have a well defined standard of what should be considered "good".
But, as it often happens, he forgot to design it in a way that errors happening in the event part of the loop be traceable in the invalidation part of it. Thus, his toolkit made everything built with it very hard to debug.
And oh, on the performance claim? The fact that often happens with these toolkits... is that their built-in event / invalidation loop made performance better for their demo use cases - but it also made everything else mysteriously slower.
This, indicates a general lack of rigor in modern framework designs.
When the foundations of your apps are already shaky, the stuff you do would of course have to be mundane - because you're spending a lot of time debugging or working around the toolkit itself.
This is why programming, at this moment of time, feels like plumbing. We're being paid top salary to do stupid things over and over.
Ideally, each toolkit designer should have written in a concise language what improvement their tools have brought and how general these improvements are. Kind of like proving the closure property in group theory. i.e. if you do this and that from this state, you'll still end up with a state with the same desirable properties. The desirable property could be e.g. you can still trace back to the error in the stack trace; or, our toolkit have not made performance worse by a small constant factor in the worst case (right now, we can easily be seeing O(n^2) surprises in places we do not expect).
The recent distributed systems tools are moving in the right direction, I think - because by requirement, screwing things up in a large scale system is very costly. So when people are making distributed system tools (e.g. ZooKeeper), they tend to be a lot more careful. There are usually a standard set of desirable and undesirable properties of the system, and easy-to-use proofs on whether an operation you perform on the system would retain the desirable ones.
That, is math. It doesn't involve partial differentiation, but the point is - it's rigorous and reliable.