Anhedonia

То есть varName : TypeName вместо TypeName varName ?

Читабельность. "идентификатор varName содержащий TypeName" намного логичнее записывать именно в таком порядке. Ну и да, этот синтаксис не новый, далеко не новый.

Вручную написать коннектор и описать все объекты используемые при обмене - все то, что генерируется по WSDL-автоматически. Риторический вопрос - а зачем придумывать себе гемморой?

Язык "на любителя", если не сказать грубее, платформа сырая, библиотек мало, фреймворков полноценных нет, производительность низкая. Писать асинхронную лапшу на js удовольствие сомнительное, специальных средств поддерживающих асинхронность в языке нет. Единственный плюс ноды, что на ней хорошо собирать статику - всякие гранты, галпы, но это для верстальщиков больше чем для разработчиков. Я вот наоборот не понимаю мотивацию людей, которые пишут на ноде веб проекты. Нода подходит только для написания промежуточных звеньев между бакендом и фронтэндом, которая особо ничего не далает и не имеет сложной логики, а только делает несколько запросов в бакенд и выдает их на фронт. И даже в этом случае я бы предпочел другое решение.

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

На самом деле основные отличия другие:
Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

нет

Основная проблема вашего варианта, то, что количество лекарств в курсе ограничено - а что, если их понадобится 100 или 1000? В таблице будет столько же столбцов? Это решается тремя таблицами. Вот псевдокод:

# Это курс - он связан с моделью юзера
class Course(models.Model):
    days = models.IntegerField()
    start_date = models.DateField()
    user =  models.ForeignKey(User)

# Это лекарство - оно само по себе
class Med(models.Model):
    med = models.ChoiceField()
    time = models.ChoiceField()
    med_amount = models.CharField()
    med_type = models.ChoiceField()
    descr = models.TextField()
    video = modesl.URLField()
    week = models.ChoiceField()

# Это связывает курс с лекарством (и позволяет присваивать их неограниченное число раз)
class CourseMed(models.Model):
    course = models.ForeignKey(Course)
    med = models.ForeignKey(Med)

Используя встроенную админку такое приложение можно написать минут за 15

Напиши мобильную версию тостера

String[] cheats = {"de.Kradxn.Xray", "Sunstrike"};	
Package Check = Package.getPackage(null);
for (String item: cheats)
    if (Check != null && Check.equals(item)) {
        System.exit(0);
    }
}

Нет.

Отправляем пользователю ссылку на свой сервер вида
васяпупкин.ру/смотри_большие_сиськи
У себя на сервере сохраняем ip всех, кто переходил по ссылке

java!