Предисловие. Что-то я не в настроении был поддерживать заданный стиль общения, ну, вроде "если ваша религия запрещает вам думать прежде чем разевать хлебательное отверстие, то не надо вываливать всё это в форум" и не собирался вам отвечать. А сейчас что-то время появилось, дай, думаю, все же попробую объяснить, не только же вы форум читаете.

Значицца... Начнём с откровения

он имел ввиду не "надо вот так", а "а вот иногда бывает вот так очень удобно".

Вообще-то так можно сказать про все паттерны и/или архитектурные принципы. Для каждого есть подходящие условия, когда их полезно использовать, и неподходящие условия, когда их использовать просто вредно. Тот же монолит (хотя его любят путать с big ball of mud) часто выгоднее (удобнее) чем накручивать модные микросервисы.

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

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

Пример: в начале проекта Z речь шла о десктопном приложении, которое должно легко и быстро устанавливаться любой секретаршей, нужно только на год-два, пока не заработает проект Х (с веб-интерфейсом, десктопным и андроидным клиентом, одновременно поддерживающим до 100к запросов в минуту и те пе) никакой поддержки не надо. Что лепим? Монолит. Структуру стараемся сильно не нарушать, но главное - стоимость, потому что всё равно выбрасывать и поддерживать не надо. Фанатично отвергаем всякие "а давайте вынесем модуль для рассылки почты в облако" или "а давайте сделаем чёткий интерфейс между GUI и бэкендом". Не надо. Быстро слепили и в продакшен. Но. Проходят полгода и гениальные менеджеры внезапно меняют решение. И радуют всех своим решением - так как Х задерживается, и вообще что-то слишком много стоит, мы его закрываем, а ваш Z очень понравился всем секретаршам, мы просто расширим его функциональность до той, которую обещал нам X, и начнём поддерживать его добавляя новые фичи по требованию клиентов в течение следующих н-цати лет. Вы же за полгода написали с нуля? Ну вот вам еще целый год, и штоп было сделано! Вот тут придется менять религию. Потому что с монолитом такого размера мы через 3 месяца скатимся к комку грязи.

я просто понимаю так, что если нужно ВСЕГДА действовать самым прямым, простым и всем понятным способом

Отож. Осталось разобраться какой же способ для всех понятный, самый прямой и простой. И полетим к звёздам. Завтра же. Кстати, а как вы понимаете для чего нужны паттерны? Можете буквально в 1-2 предложения написать? (можно больше)

одним из теоретических преимуществ вммв (или мввм? какая *й разница : ) является утверждение, что таким образом можно разделить команды разработчиков вью, модел и вьюмодел так, что они вообще ничего друг о друге не должны знать.

Что вы курите и откуда такое берёте? Хотя, не удивлюсь если найдётся цитата кого-нибудь из мелкософта, они всегда отличались умом и сообразительностью.

а как вы вообще приступаете к созданию нового продукта?

Последние два раза по скрамовской методичке - с менеджментом определяем product vision, MVP, personas. Пара встреч с заказчиками и предположительными клиентами, заставляем родить несколько user stories. Потом определяемся с менеджментом с нефункциональными требованиями и их приоритетом, вместе с командой выбираем религию для проекта. После пары спринтов, ревью и пожеланий ПО, хватаемся за голову, меняем религию, воюю с менеджментом, объясняю почему надо выбросить всё и начать заново, выбрасываем половину, работаем дальше.