вы же сами всё написали
в тех рамках что вы озвучили главный паттерн это херач отсюда и до заката

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

ну так и надо задавать вопрос

нее, всем не угодишь. Тогда начнутся ответы в духе "а вдруг тебе завтра понадобится тестировать. Лучше делай сразу"

смотри ты заказал мастеров поставить тебе стеклопакеты вместо старых окон
ты предъявдяешь требования к резульиату
но не спрашиваешь какой дрелью они будут сверлить

паттерны это инструменты разработчика

менеджеры тут причем?

оффтоп уже начался или еще нет?

если ты владеешь инстумениом ты просто говоришь я сделаю это за N часов
если менеджерам приходится слушать про MVP и мокси это плохо

элемент с менеджером нужен был для описания рамок(условий) разработки проекта

хорошо тогда по другому
тебе как лучше?

я например не умею без тестов и MVP

с мокси моя производительность выше в 2-3 выше чем ьез неё а значит и стоимость продукта ниже

но это моя история
как у тебя не знаю

я спрашивал, для того, чтобы понять есть ли смысл в данном примере подключать ненужные инструменты, или же они в данном примере moxy не будет являться ненужным и принесет пользу не сразу, а 3м месяце разработки

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

поэтому я и спросил: "Будет ли этот инструмент ненужным?"

я же ответил
ты скажи
нужен он тебе или нет

хотя по сути вопроса сдается что не нужен

по-моему - нить разговора утеряна

ребята утром подключатся и разрулят

у меня сложилось ощущение что вы и есть тот менеджер)

что вам нужны аргументы почему презентейшен слой и тесты и перевороты это плохо)

я могу ошибаться)

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

У Мартина есть хорошая фраза в книжке, вроде "таким образом, мы понимаем, что архитектор должен уметь видеть будущее". Вот у вас та же ситуация)
Преимущество одно таки есть: автоматический детач View. Спасет вас от крашей при попытке обращения к UI после того, как фрагмент уже уничтожен.
Пример: вы делаете сетевой запрос, и до его завершения закрываете экран. Без Мокси вы вынуждены отменить эту операцию где-то в onDestroyView, или будет краш. Это легко с Rx и корутинами, но нелегко с коллбеками. Мокси позволит вам чуток расслабиться, и не отменять коллбек, потому что результат вернется в презентер, тот позовет вьюстейт, а тот ничего не сделает, потому что вью открепилось.
Другие преимущества - разделение кода (проще поддерживать), и future-proof, когда менеджер таки придёт и спросит, а чего это мы экраны не даём поворачивать.

Спасибо. Не думал про эту деталь

Подскажите пожалуйста в каких случаях вызывается onDestroy у презентера?

точнее всего вам ответит код библиотеки. Если кратко - когда View (активити или фрагмент) уничтожается насовсем