Прочитал статьи. Я решал схожие проблемы, но по своему. Эволюционным путем у меня получился гибрид clean, Android architecture component, rxjava. От clean примерно такое же, чуть облегченное, разделение по слоям. От AAC - Room, View Model. Датабиндинг мне сразу не понравился даже пробовать не стал. Так вот, паттерн State я реализовал по классике, владелец состояния Interactor, меняется оно извне и т.д. Связка View + View Model AAC как то сразу зашла, поток от View к Interactor идёт обычным способом без Rx. А вот обратно - через Subject, и я уже нашел Уортоновские релеи. Единственная некрасивость в том что а View у меня приходит объект который содержит enum тип команды и данные к ней в виде кучки полей для всех команд. В View по switch все это разруливается, не делал отдельные подписки на команды.
То что ты описал в части команды с енамом и всеми полями - это ближе к unidirectional dataflow. Или как любят называть в сообществе MVI. Тоже имеет место быть, но отличается от RxPM тем что поток один а в нем состояние всего экрана сразу. Но особо плюсов относительно RxPM мы не видим. Сделать сразу много подписок не сложно, комбайнить их в PM удобнее, чем разруличать switch во вью. Ну и еще были практические моменты, которые не очень заходили. Как-то так.
