Yes and no.
In a perfect world, you would like to write the code as if the asynchronous requests to the server foo(), bar(..) and baz(..) were able to block:
FRP code ends up being structured in a more state machine-like "data flow" style, with nothing resembling a flow of control, so it doesn't allow you to write code in the style given above. If you're read chapter 13, you'll know what I mean about a "data flow" style. I/O is usually modelled as...
...where bar(..) is a function taking Stream<A> and returning Stream<B>. So you could write this code as:
sVar0 would be a stream of type Stream<Unit> and it would be needed to initiate the communications (assuming foo needs no input value). Now this does not handle errors, so you would need to add extra logic to deal with them. Picture it as a diagram with boxes and arrows - each async request having an "error" arrow coming out, like in chapter 13.
So this definitely can be done in FRP, but FRP is not as good for this kind of problem as the imaginary blocking I/O method described above. Given that this isn't available, it may still be a good option. Note that it is trivial to implement something equivalent to a promise in FRP.
Where FRP does really well is in situations with complex, multi-variable state machines - where all other approaches fail badly. (Video games and GUIs are good examples of this.) Your problem is basically a single variable state machine, where the variable is "where we are up to in the communications." In the blocking I/O model, this state variable is modelled as the current execution position in the flow of control.
I've got a chapter 10 Battle of the Paradigms that illustrates this point by comparing FRP against "actor model" which is really this flow of control style. The problem in this chapter is drag-and-drop again. There are some similarities between it and the I/O problem you presented.
In chapter 11 I deal with the question of asynchronous I/O more directly.