Козел отпущения или MVC в iOS

Тоже не уверен. Без знания бизнес требований к продукту очень сложно судить по единичным параметрам. Вполне могу себе представить ситуацию, когда требования от PO или BA были что-то вроде: «Нужно отправлять геолокацию на сервер каждые 15 секунд, это нужно для аналитики» или «нужно обрабатывать граф друзей при каждой загрузке фида для отправки нового запроса на рекомендации в друзья» и т. д.
Опять таки, не думаю, что в компании в которой работает 100+ iOS разработчиков никто не следит за performance метриками и думаю этот вопрос поднимали и решали не раз, но требования, как известно, ставят не программисты.

Никогда не судите работу таких крупных сервисов только по себе. У меня на 5ке работает идеально, а у жены на 7ке — вообще космос. Жор батарейки может случаться от миллиона причин и не все разработчики в принципе могут контролировать.
В фейсбуке явно работают не дураки

Поставьте себя на место пользователя. Почему я должен скачивать очередное приложение более 100МБ и тратить свой трафик? При этом в приложении невозможно найти нужного функционала под кучей ненужного хлама.

Опять таки, не вижу никакой связи между юзабилити приложения и качеством кода. С другой стороны я прекрасно вижу зависимость между юзабилити и качеством продукта. Если это то, что вы имели ввиду — тогда я с вами согласен.

Если вы делаете приложение для пользователей, а не для менеджеров:
— размер приложения должен быть минимален насколько это возможно (вы должны уважать трафик и время пользователя потраченые на ваше приложение)

Почему вы решили, что размер Facebook не минимален или не стремиться к минимальному размеру? Почему вы решили, что нет уважения трафика и времени пользователя?
Я думаю, что 99% решений в Facebook, абсолютно не зависят от разработчиков. Многое продиктовано требованиями продукта и иногда просто невозможно сделать «быстрее, легче и меньше» по поставленным требованиям.

— открытость приложения (убрать все ненужные элементы и сделать явным самый необходимый функционал)

Опять таки, как это относится к качеству кода? К качеству UX — да, к качеству кода — нет.

Если работаете за зарплату и на удобства пользователей вам плевать — то смысл было писать эту статью?

И где я говорил, что мне плевать на удобства пользователей?

Только пользователь будет оценивать вашу работу, не менеджеры и не другие программисты.

На своих проектах — я полностью с вами согласен, но в случае facebook я думаю, что ни один отдельно взятый программист не может оценить домен пользователя, то что неудобно вам, может быть абсолютно удобно другим пользователям. А «менеджеры» и «UX дизайнеры» и прочие «не программисты» как раз очень много занимаются этим, проводят юзер тестирования, оценки и т д, и очень часто отдельно взятый программист не может и не должен принимать важные продуктовые решения, только потому, что не обладает достаточной информацией или знанием предметной области.

Сравните с приложениями из других социальных сетей.

И?

TechMedia(приложение от хабра) 52МБ
В десятки раз меньше по функционалу чем Facebook, а по размеру всего в 3.5.
Steam 30МБ
В основном одна большая web-view. Половина экранов — не нативные.
Instagram 49 МБ
Часть facebook. Принципы работы одни и теже.

Вы откройте приложение Facebook и посмотрите сколько реально экранов вы там можете найти, в коде может присутствовать скрытый функционал.

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

Но принцип единой ответственности говорит о другом

В чем ответственность UIViewController тогда в данном случае?

Кроме того в интерфейсе UIViewController нет ни намека на наличие у него модели

Это потому, что по идее ViewController может использовать различные модели, или различные типы моделей. Поэтому реализация взаимодействия модели и контроллера лежит на разработчике.

Аргументация — SRP.

Хорошо, и что за responsibility?

Более того, один экран может иметь несколько слабо связанных элементов, каждый такой элемент должен контролироваться отдельным контроллером (презентером)

Если нам не нужно реагировать на события жизненного цикла вью (viewWillAppear: и т.п.) или взаимодействия с другими вью конироллерами (willMoveToParentViewController: и т.п.), то можно обойтись набором UIView.

Т.е. вы сами себе немного противоречите? Вы говорите, что разбиение на слабо связанные элементы управляемые контроллерами и в то же время говорите, что разбиение на контроллеры избыточно и можно обходиться только UIView.

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

Если перечитаете пункт 3 из статьи — то вы как раз можете найти теже самые подходы.

Например UITextView — наследник UIView, а не UIViewController, хотя логики там будь здоров.

И во многих случаях, я считаю, имеет смысл создавать контроллер, который будет управлять логикой UITextView, для того чтобы не выносить эту логику в общие контроллеры.