Central to the understanding of cycle.js is the concept of observables. An observable is powerful abstraction, as it allows event streams to be programmable. However, an overreached abstraction can be even worse than a lack of abstraction. Cycle.js gratuitously applies the observable abstraction to its component model.
The cycle.js notion of a component is a object that takes multiple observable sources, and emits multiple observable sinks. I have to admit, at first I didn't see this as problematic: to the contrary - it actually struck me as elegant. What I didn't realize, before building a real-world project with cycle, was that this meant all interactions between components were asynchronous. So each component cannot even access the state of another component without communication via observables. This introduces enormous needless complexity into an application. Not only do you have to pay an up front mandatory boilerplate tax to minimally wire together your components, you'll tie yourself in knots readjusting that wiring to get those components to communicate with each other in the way you need.
We actually ended up re-writing the project with our own framework, pickle: https://github.com/pickle-ts/pickle For us, this substantially increased maintainability / reduced the code size of our application compared with cycle.js, or the prototype we wrote with react/redux. The code reduction came from realizing the appropriate abstraction: the entire application should be composed of an object-oriented hierarchy of stateful components, where on each update, these mutable components render themselves as immutable v-dom trees. Anyway, to counteract any pluggishness (our framework is obviously super new so is only of interest to ultra early-adopters), the conservative sensible choice for a web framework right now is to use react or vue /w a state manager. Not cycle.js.