What other direction is there?

The best way to visualize unidirectional data flow is in a top-down fashion. Data starts in one state at the top, changes state as it flows downward, ending with a side-effect that does something with the data. When this is enforced as a property of the architecture, side-effects are predictable. We can easily trace the starting point of data, through the transformations it makes, ending with the visible side-effect.

When we don't enforce a unidirectional data flow, it's difficult to trace cause and effect. This is the main reason that Facebook started promoting the concept with the creation of Flux—to prevent components from changing state at will and passing the changed state on to another component. For example, let's say that you aren't using immutable data, and that one component changes its state in response to an event. Then some other component that references this state renders itself, causing its state to change as a result of the first change. These are nothing more than uncontrolled side-effects.

Immutable.js is a low-level library compared to the ideas of Flux or a UI component library such as React. Even if you're not using either of these, you can still leverage Immutable.js to build a unidirectional architecture.