У меня есть одни слова от автора @ZeroBias эффектора на тему почему появился effector и какие его плюсы.

Децентрализованность, декларативность, эффективность. Требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи.

Сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд.

Сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения.

Принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. Это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести стейт модалки из реакта. По совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст.

Возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты.

Независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому api библиотеки использует только функции и простые js объекты.

Предсказуемость api. Небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. Зная как работает .watch в событиях, можно догадаться, что делает функция .watch у стора.

Приложение строится из комбинации базовых элементов и возможности строить новые.
Нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её.