I didn't say "observables are not asynchronous", I was referring to the comment "interactions between components are asynchronous" which to me sounds like "event emission and propagation". Propagation is often synchronous when using RxJS 6 which uses by default the recursive scheduler, and with xstream, which is similar. For instance, event emissions along the chain a$.map (f).filter(g).take(10) are synchronous. But I suppose the confusion here is what people mean with "asynchronous". To me it means a set of computations that are allowed to happen sparsely, with other computations potentially happening in between. A lot of people assume that callback-driven code in JS is necessarily async (and maybe that's what you meant with the use of the word), but it's common in the JS reactive programming community to recognize that callbacks can also be executed synchronously, for instance array.forEach(cb) is synchronous although it's callback-based and as such could have been asynchronous through the same cb API.
Andre - the point is that the inter-component wiring between cycle.js components is verbose and unwieldy due to the asynchronous-capable protocol. Definitions are of course important, but in this case dwelling on them is to side-track a criticism, rather than to address that criticism directly.
With observables, they can be executed synchronously or asynchronously in JS, but it's a bit of a leaky abstraction when you have to be aware of the internals of particular stream operation to known whether it is synchronous or not, so to avoid unnecessary complexity you need to assume asynch behavior for all streams.
