In theory that’s true (although observables are for reactivity too), but Angular uses observables for its http library and http requests are very much not streams. It’s one of the main downsides of working with Angular, the http library is mediocre and does come with the added overhead and complexity that rxjs brings.
Until this release (if you only use stable features) using forms meant dealing with observables too, even if you just want to read data when submitting a form and validating some data on change/blur.
And often you’ll find that your data from promises, observables and signals need to interact with each other, which can be annoying.
Fortunately the situation with signals and their async usage is improving, and iirc the Angular team wants to make rxjs optional, but until it is Angular can be a confusing mess on some points.
I partially agree, there is an overlap between signals and rxjs, however the core business is different- observables are about data manipulation, while signals are about efficient state management.
Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and using DI it’s a drop in replacement.
But why is push vs pull the definition of reactivity?
I suppose we can say that there are different kinds of reactivity. Signals is one kind. Observables à la rxjs is a different kind (the whole model of programming with rxjs was referred to as "functional reactive programming"). Observables are push-based. Signals, as I heard, are a more complex primitive, which, under the hood, is push-pull.
React's reactivity model may be crap; but this doesn't make it non-existent.
Promised - async
Observables - streams
Signals - reactivity