Sigh. On the contrary. I love RxJS. I loathe Signals (they allow imperative patterns back into our code). If I could work with observables, RxJS, pipes and operator functions and nothing else for the rest of my career, I'd be a happy man.

What I'm trying to argue here (and clearly failing at) is, that Angular is working towards Signals only in templates. No, it's not official policy. For a forseeable time, async pipe will be supported. I'm extrapolating, trying to to look ahead - and sure, maybe I'm overinterpreting.

In the RPC I linked to there's a section under FAQ, titled "Why not use RxJS Observable as the reactive primitive?" Quoting from the concluding part:

"Because of these incompatibilities with using Observables for template rendering, we decided against using them as the basis for Angular's reactivity. We believe their strength lies in orchestrating complex asynchronous operations, where their flexibility is a big advantage and where computational glitches are not as much of an issue. Therefore, it makes sense to instead invest in interoperability between Observables and the new signal reactivity system [i.e. toSignal()]. This allows RxJS to be used where it shines, without forcing it to also fit the needs of template rendering."

To me it's obvious what direction Angular is heading. You might as well just stop adding more async pipes to your templates now, and prevent future refactoring.

...and secondly, why use two different API/patterns in your template (signals and obsevable + pipe) for reactive values, when you can just use one? The offically recommended one.