Component here is just to illustrate that the type is of a view component, and due to it being implemented on top of React. `component()` is a factory/syntactic sugar on top of React allowing you to have referentially transparent components (as you get arguments passed to the render function).
In time, React hopefully (and probably) gets support for stateless functions without the syntactic sugar (https://github.com/reactjs/react-future/blob/master/01%20-%2...). This will be supported when React adds support for functions returning VDOM elements.
With Omniscient there is a syntactic sugar on top of React class factories, which encourages to think of components as pure and smaller/more focused functions. This tries to lead more to simpler and composable components.
Yeah. The main part here is using immutable structures from the top, having cursors to sub-components with information about only the relevant data for that component, and have a way of re-start the loop when a data has changed.
Sometimes, though, we need to communicate to a parent or ancestor (e.g. to delete an item in a list). For that we can simply use events (or possibly callbacks) passed as statics to components. (Statics are values that doesn't trigger a component update when changed.)
It doesn’t really relate to the Flux architecture directly. You could probably use something like Flux in addition to Omniscient. In the same way that Flux encourages a continuous loop with data from the top, Omniscient has a single direction of data flow. But you could easily use dispatchers with stores to communicate in the other direction, like with the Flux architecture.
Omniscient is a very small library, only providing a “smarter” shouldComponentUpdate for use with Immutable.js cursors and a wrapper for easily creating components with renderers and composability with mixins in focus. See the documentation to see more about Omniscients rationale: http://omniscientjs.github.io/documentation/