Ну там в Examples их немного, такого рода, но должны быть + я в скором времени добавлю и такие.

По поводу lift например я юзаю styled-components и их опорачиваю в lift'ом

когда нужно, что бы они слушали изменения атомов.

Со стороны чтения данных вроде все ясно. Как быть с обновлениями? Вижу set() и становится плохо :). Какие преимущества по сравнению с flux/redux/etc?

Да там set и modify. И в этом нет ничего страшного. По поводу сравнения нет холиваров между Mutable или Immutable данными. Есть Observable. Как по мне самый удобный механизм хранения данных. Преимущества в рендере, я не фан прокидывания всего контекст и менеджментом коннектом как это сделано в Redux. На больших объемах данных приложение умирает. Так-же с атомами довольно удобно работать, можно их и логировать, и так же делать тайм тревелинг (правда пока это на уровне примера, а не в библиотеке). Бенефиты есть и я бы больше сравнивал его с MobX, а не с Redux. А тут уже холиварная тема

Но обсервабл по определению тоже не очень укладывается с сеттерами

так будет история о причине создания? или интрига ...

У обсервабла есть producer, единственное место что пушит данные. Делать это извне — грешновато

игра слов великолепна

Ну тут из-за этого и Atom, есть атомы без обсервабл тоже

Реально игрла слов)

То есть атом — не обсервабл, но сделан на основе обсервабла

В вашей имплементации

Там они разные, но основной extends от Observable

Почему не сделать чистый state managment как redux?

Тут же в зависимостях react

Некошерно совсем

И я так понимаю оно только для F

в каком смысле? что бы можно было работать в связке с rx