Мне как питонисту очень удобен Stylus отсутсвием скобочек и привычные отступы))

В вашем же примере LESS не получится того, что выше написано на СSS
У вас получится .button.search и .button.cancel а не как выше в CSS .search.button .cancel.button

stylus:

.button
  border-radius 4px
  border 4px solid black

  .search&
      background-color blue

  .cancel&
      background-color red

Раньше тоже пользовался и SASS и LESS но в последнее время Stylus применяю

Лично я всегда пишу новые большие долгосрочные проекты на django которая еще не вышла, чтобы к моменту релиза не делать снова рефакторинг, да и заодно наиграться вдоволь с новыми фичами и багрепортить. Для меня релиз django 1.8 означает что пора юзать 1.9

Да ладно, чего ждать то)) разработчики тоже не дремлют. Я вот с 1.8 уже много месяцев, а у некоторых модулей если и нет релизов на pypi с поддержкой django 1.8. то в репах в разных бранчах(типа develop или dj18) то точно есть. South уже давно не актуален.

Если вы имеете ввиду почему лучше использовать шаблонизатор jinja2 а не родной джанговский — то, стоит отметить, что jinja2 намного быстрее и там много интересных штук типа миксинов)) Гораздо более производительное и удобное решение.

Эти решения наоборот дополняют то, что предложено в django(по сути предоставляют уже готовые расширения для jinja2 для использования привычных тегов django, эти теги так-же позволяют не переписывать все шаблоны на jinja2 а использовать обычные джанговские, если для них есть расширение). Кроме того, django-jinja позволяет использовать шаблонизатор jinja2 и в более ранних версиях django.

Для работы с jinja2 шаблонизатором в django, советую использовать django-jinja или jinja2-django-tags.

Все замечательно, только не хочется использовать celery.
Раньше активно пользовался celery, потом перешел на использование rq/django-rq а впоследствии пользуюсь uwsgi spooler

OVH — c 2007 года вообще никаких проблем не было

Так как я деплою django проекты через uwsgi, могу порекомендовать к прочтению это — там описано несколько различных способов.

Я собирался пойти, но проспал =( Посмотрю тогда видео докладов и полистаю слайды презентаций.

А почему не воспользовались готовыми наработками? например у github.com/ramusus есть полно репозиториев по теме.
Может вам пригодится github.com/ramusus/django-vkontakte-wall

Сам уже давно интересуюсь и экспериментирую с polymer и мозилловским X-Tag, но в продакшене пока побаиваюсь использовать.

Еще про мулов забыл сказать.

Так там просто выводится статистика именно того uwsgi под которым работает эта админка. Там грубо говоря просто статистика и возможность перегрузить а нет возможности создать нового вассала или поменять его конфиг.
Выше же я имел ввиду сделать что-то типа админки для управления сразу всеми вассалами — типа что-то типа панели хостера например, где ты видишь все запущенные вассалы и можешь ими рулить.

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

Если у вас есть необходимость останавливать какого-то вассала, а проектов прямо куча, то уже только ради удобства использования я бы советовал вам держать конфиги вассалов например в mongodb или в postgresql. если вассала из бд удалить или пометить неактивным — процессы этого вассала останавливаются, при добавлении в бд нового вассала или если пометить его активным — автоматом стартуют. У меня в планах было сделать простенькую админку для таких целей в рамках django-uwsgi чтобы через нее можно было править конфиги и перегружать вассалов и поддерживать все возможные способы чтения конфигов у uwsgi
P.S. все равно считаю что хранить конфиги в репе очень желательно, при деплое например их использовать или нет — дело десятое, но хотябы в качестве примера работающего если вдруг срочно надо будет составить конфиг под конкретно этот проект а сисадмина или кого-то еще рядом нет…

Их можно запускать отдельно

Оч хороший вариант. Я иногда и целые джанго проекты запихивал в .deb-ки и деплоил через apt)
Еще как вариант установить uwsgi в какое-то отдельное виртуальное окружение и просто оттуда его вызывать /path/to/virtualenv/bin/uwsgi или с помощью github.com/jsvine/envplus который может одно вирт окруж комбинировать с другими. У меня например есть окружение со всем связанным с postgresql там и psycopg2 и всякие django-hstore итд, и я чтобы при разработке не ставить все лишний раз в новое окружение просто прописываю envplus add имя_нужного_окружения(ну естественно я заблаговременно подготовил несколько тематических окружений по разным нуждам и систематически обновляю в них пакеты)