As someone who writes + maintains systems with both: They both have their place. Reactive streams (FRP, Rx, ...) are good when you want to do operations over streams like 'fold', 'sample', 'tween', etc., but most code isn't like that. Instead, most code is 'at-most-once' (=> value or exn), where async/await is enough. That matters because adding streams means all of a sudden your code looks like 'one-or-more', which adds an entirely new world of behavior to define & test against. ("Is this a value or a stream? If I feed in a stream... What if I just want one...")
'Behaviors' in FRP help a bit here... but if you can avoid the complexity, why not?
For when we do FRP, I like how we got it in our React code: Mostly synchronous functional code (React::render(), ...), and then we do animations and other stream-like concepts via Rx. Our nodejs code works similarly: mostly async/await route handlers, and now and then we do fancier http streams and whatnot via Rx. (Though even there async/await has been increasingly nice, as we generally aren't doing many fancy temporal operators nor contention handling.) We haven't figured out an equivalent solution for our Python async code, however as async/await is still new & changing, and afaict FRP/Rx never really made it there.
'Behaviors' in FRP help a bit here... but if you can avoid the complexity, why not?
For when we do FRP, I like how we got it in our React code: Mostly synchronous functional code (React::render(), ...), and then we do animations and other stream-like concepts via Rx. Our nodejs code works similarly: mostly async/await route handlers, and now and then we do fancier http streams and whatnot via Rx. (Though even there async/await has been increasingly nice, as we generally aren't doing many fancy temporal operators nor contention handling.) We haven't figured out an equivalent solution for our Python async code, however as async/await is still new & changing, and afaict FRP/Rx never really made it there.