Саше можно доверять в этом вопросе. Он был тимлидом в LinguaLeo, а потом в СберТехе. Так что, кто как ни он, знает как лавировать между бизнесом и тех.долгом))

Про рефакторинг снизу я больше имел в виду выкорчевывание с UI сначала работы с данными, потом бизнес-логики и т.д.

например, был жестокий и перегруженный CursorLoader прямо в Acitivity и мы аккуратненько перенесли это (по уровням данных и бизнес-логики) и оформили в виде RX?

тоже отличненько, думаю) правда, как мне кажется, потом вынесенные части тоже надо будет как-то рефакторить (не все же сразу красиво получится). Но и про вариант "сверху" можно сказать тоже самое)

все зависит от исходного кода и его запущенности) правильный вариант ответа - этот тот, при котором ничего не развалится при приемо-сдаточных испытаниях и после них)

Кейс. Данные приходят с сервера и кешируются в бд. Данные подгружается в бесконечную ленту страница за страницей.
Обычно данные сначала появляются из бд, отображаются во вью. В какой-то момент прилетают новые и нужно найти разницу между теми данными, что уже во вью и теми, что пришли из репозитория, затем уведомить адаптер, что именно поменялось (notifyItemChanged/inserted).

Стоит ли хранить 2 списка данных - в презентере и в адаптере? Как иначе презентер сможет найти diff? Не думаю, что этим должна заниматься view - это же уже логика отображения...

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

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

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

оставить кого-то на поддержку старого, тем временем другие разработчики пишут новое и потом постепенно юзеров мигрируем

это если хочется дизайн в корне сменить

Просто если приложение писали несколько лет нифига не проще

И я говорю про рефакторинг без изменения UI

ну, если писать новое, то можно из старого взять какие-то решения.

Зато новое можно писать сразу с более чистого подхода к архитектуре

но, на это конечно нужно одобрение менеджеров и прочих

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

можно дома рефакторить в свободное время, если сильно хочется и не лень ))))

Дома хочется чем то другим позаниматься)

Это практически нереально, что вам дадут просто переписать.
Я даже не припомню таких случаев. Бизнес просто не даст. А еще он хочет постоянно новые фичи. Да, они понимают, что нужно отрефакторить приложение, но сделать это нужно параллельно с новыми фичами.
Это жизнь