I'm not sure pull is any better in this regard. Simply stated, naive push and pull are both bad. You wind up putting a fair bit of heuristics on top of either to make them good.
Pull has the major downside that you never know when you need to pull a new value. Which is a pretty major downside.
And really, this does just feel like we baked some new semantics onto the observer pattern.
It depends on your point of view. From one perspective, the observer pattern is simply a way to implement reactive values in the OO paradigm - indeed, a somewhat arrogant FP aficionado would describe many of the GoF design patterns as clumsy OO emulations of things a functional language would be able to express much more elegantly.
In the Rx-style reactive model the big thing is making the event streams, in addition to the events, first-class objects, so they can be composed and manipulated with the usual FP subjects like map/filter/reduce. This makes, for instance, throttling to optimize the propagation of changes almost trivial compared to the situation where you only have individual events without context.
Yeah, I've read some of the papers. I was even heavily swayed for a time. However, I'm not entirely sure that Streams are an automatic win in abstraction. Often combining streams is just a very clumsy way of saying "add this and that."
More specifically, I think things are a lot easier when you can work way above those abstractions. As soon as you get into the weeds, all of the abstractions suck.
I also think this is specifically why people like angular so much. For many use cases, you are just setting values and having the UI present said values. Note, setting values, not appending to streams.
Now, do I expect that angular's internals would benefit from the streams metaphor? I certainly suspect so. Don't know, though.
Pull has the major downside that you never know when you need to pull a new value. Which is a pretty major downside.
And really, this does just feel like we baked some new semantics onto the observer pattern.