И я сначала хотел привести кейсы, моменты когда надо рулить сложную логику, но призадумался

forward + map

круто, вместо одного .on

децентрализованность, декларативность, эффективность. требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи
— сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд
— сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения
— принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести  стейт модалки из реакта. по совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст
— возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты
— независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому апи библиотеки использует только функции и простые js объекты
— предсказуемость апи. небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. зная как работает .watch  в эвентах, можно догадаться, что делает функция .watch у стора
— приложение строится из комбинации базовых элементов и возможности строить новые.
нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её

+

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

Можно одним словом

Вернее, аббревиатурой

DX

Это ключевой момент, с эффектором тупа удобнее и меньше шансов прострелить себе ногу

Это да

Ну пока я нашёл первое слово - декларативный, потому что в релаксин я устал от императивного кода

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

С эффектором то ж самое. Ты можешь взять редакс, реселект, санки или там саги, мучаться с ререндерингами и раздутым стором, делать прочие кульбиты. А можешь просто взять эффектор, где все эти проблемы уже заботливо решены Димой, бери и юзай

Форвард нужен
1. когда таргет уже существует, на момент создания связи
2. когда сорс или\и таргет можественные сущности

Форвард не подходит:
1. когда нужна фанка трансформации пейлоада
2. когда таргетом является стор\сторы

Ну по второй части, можно семпл заюзать

Но мы это обсуждали вроде, у меня был вопрос на счёт производного стора и .map vs sample хитрый

Я всегда за более понятные/простые варианты

DX как довод для среднестатистического разраба не особо силён, он скажет,  я вот пишу на редаксе, я к нему привык, он офигенен и у него привычный уклад

Ну пусть на редаксе пишет тогда, зачем его заставлять