Какой-нибудь визард авторизации, например

передавать фильтр через аргументы разве не достаточно?

Судя по этой схемке с android devs - да

В некоторых случаях - можно, и это будет работать. Но бывают кейсы, когда фильтры не положить в bundle из-за слишком большого их количества (когда все бренды магазина содержатся в них, например), и в этом случае можем огрести с TransactionTooLargeException.

Подождите, у вас что Активити? А что произойдёт со скопом, если предыдущие окно умрет.
На первый взгляд как-то сложно получается.

Ну, это не особо важно) Были проекты, на которых подобные иерархии экранов - это различные activity, сейчас проект с single-actiity подходом.
Управление жизненным циклом подобного скоупа вручную это действительно сложновато, но в этом кейсе мы получаем только накладные расходы на настройку подобной реализации в самом начале, и нет необходимости в том, чтобы ручками очищать и создавать его на самом экране, как если бы мы хранили подобные данные в синглтоне.

Но этот слой это что-то абстрактное. Всмысле если мы делаем в одном модуле то ничто не мешает во ВМ использовать румовские ентити. Слои ж нужны для случая смены бд, а это не очень аргумент в случае с андроид
??

Слои нужны для разделения логики. Потому что если вы будете прокидывать сущности Рума в ВМ, то ваш же кейс со сменой БД сломает вашу логику, т.к. сущности спокойно могут поменяться и вместо того чтобы просто поменять их маппинг в одном месте, вам придется выискивать где же вы в ВМ на них завязались и менять во многих местах. Опять же если проект маленький, то такое может и прокатить, но в среднем или большом я бы так уже не делал

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

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

Спасибо за ответы. Я впринципе за разделение в разумных случаях. На работе возникает спор на эту тему и доводов которые описаны здесь кажется недостаточно. Вот я и хотел услышать мнение может есть еще что

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

С чего начать изучение архитектуры приложений? Для Android разработки

С вопроса себе, зачем ты хочешь изучать архитектуру и что ты от этого ждёшь

классика - найти себе работу

во всех вакансиях требования - clean, mvvm, mvp, несколько приложений в сторе, несколько лет опыта коммерческой разработки.

+ android разработка развивается слишком быстро - пару лет назад использовали совсем другие технологии, нежели сейчас.

Начать с гугла
Погугли - сделай пару примеров по туториалам
Потом начни делать свой проект(какой-нибудь) с использованием архитектуры которой ты изучил

+- так