document.querySelectorAll возвращает NodeList, а вы пытаетесь работать с ним, как с элементом. Это ж вам не jQuery! Так должно сработать:

var elements = document.querySelectorAll('.show > ul > li');
for (var i = 0; i < elements.length; ++i) {
    elements[i].style.display = (elements[i].style.display == 'none') ? 'block' : 'none';
}

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

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

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