Сергей Родюшкин

Вроде как пишут, что можно поставить старую Xamarin Studio 5.1.4, и в ней это еще есть. Надеюсь, это поможет.
Опубликовать вручную не должно быть сложно: собираете проект, копируете ./bin, ./Views, *.config и каталоги со статикой в root-директорию сайта в IIS — этого должно быть достаточно.

Лично я сторонник такого разделения в силу практики Separation Of Concerns.
Я даже разделяю модель, модель представления и модель запроса (данные, пришедшие от пользователя).
Я люблю, когда объекты домена представляют собой POCO-классы, как правило, неизменяемые — с readonly-полями и валидацией всего в конструкторе. Для получения данных от пользователя я использую отдельные классы с атрибутами валидации, автосвойствами и автоматическим связыванием. Если все хорошо, я просто делаю маппинг в доменный объект и сохранение.
Модель представления нужна, если она комбинирует несколько доменных объектов, содержит данные, нужные только представлению, и так далее. В простых случаях возможно передавать во View сам доменный объект.
Вышесказанное имеет смысл при разработке серьезных приложений. Для простых сайтов на коленке лучше разделение не использовать, или использовать его только там, где это действительно нужно. Минусы заключаются, собственно, в дополнительном количестве кода, который приходится писать и поддерживать. Плюсы — в четком разграничении ответственности и дисциплине.

В терминологии Microsoft развертывание web-приложения на нескольких серверах именуется Web Farm. Даже framework для них сделали. Про конфигурацию еще здесь можно почитать, ну и вообще в Google по запросу «configure web farm».
Про базу данных — MongoDB замечательно масштабируется по горизонтали, начать можно с репликации, это даст масштабирование на чтение, при необходимости организовать распределенный кластер.

Похоже, проблема в том, что метод, принимающий аргументы фильтра, работает только по POST, а пейджер реализован в виде ссылок, которые, очевидно, делают GET запрос (и вы попадаете в первый метод).
Думаю, вы могли бы сделать один GET-метод, Index(FilterAutoValue filter, int page = 1) и, если критерии поиска не заданы, просто возвращать из dataFilter.FiltrationAuto запрос, отображающий все.

Не совсем понял суть вопроса.
Если работа с данными в вашем проекте вынесена в отдельную библиотеку и MVC-приложение использует эту библиотеку, ничто не мешает рядом с MVC сделать еще одно приложение (console или service), которое будет работать независимо, используя те же библиотеки. Консольное приложение можно запускать через scheduler ОС, если сервис — тут вы сами решаете, когда и что нужно делать.
Если код работы с базой (контексты, модели, да хоть бы ADO.NET) у вас в MVC, то стоит сделать рефакторинг.
Для коммуникации между приложениями MVC и не-MVC можно сделать специальный endpoint (в случае console -> MVC), или event queue (для console <-> MVC), но это при необходимости.