Почему стоит использовать препроцессоры

Увы, но, похоже, что нельзя.

Почему стоит использовать препроцессоры

Какой-то вы агрессивный.

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

К счастью, ко мне никогда не приходили менеджеры, да и не переверстывал я настолько, что нужно все менять.

И как это поможет понять человеку, что означают буквы 'md'? Вы каждый раз, когда они встречаются, пишете комментарий? Если так, то это первый признак дурнопахнущего кода.

medium. Это не так сложно, если открыть всего один файл mixins.scss

IE — да, что поделать, вы же сами выбрали этот путь.

А потом надо будет искать исходник и делать всё по новой.

Лол, а если был бы CSS, изменения в Dev Tools из коробки (а вы за это ратуете) сразу бы в файл писались?

Почему стоит использовать препроцессоры

Да, я заметил ваше решение. Изящно, мне нравится.

Почему стоит использовать препроцессоры

Медлительность — отличный довод против.

libsass

А теперь вспоминаем сколько раз реально приходится что-то менять? Правильно при редизайне один раз за один-два года! Да find/sed работают куда быстрее чем пересборка на каждый чих. На внедрение препроцессора куда больше времени уйдёт.

Это лишь пример использования. Мощь переменных в разы больше, нежели простой список цветов (например, в том же BrandButtons я использую переменную для массива)

Функция, которую почти никто не использует. Всё равно цвет задаёт дизайнер, а что копировать из макета абсолютно всё равно — на работе это никак не сказывается.

Функций больше.

Плохая практика, которая только мешает читать, так как глаза скачут по отступам. Особенно весело, когда пойдут изменения (а они будут): элементы начнут переезжать с места на место и т. д. Только БЭМ может с этим работать.

Не знаю, что у вас за метод разработки, что элементы едут с места на место. Глаза скачут по отступам? Вы их вообще не ставите?

В редакторах давно есть те же сниппеты, превращающие две буквы во что надо. И удобочитаемость кода выше.

bourbon.io/docs/ и многое другое

И в IE8? И на девайсах? Отладка — значимая часть работы верстальщика, и тут производительность как раз упадёт.

На девайсах — да. IE8 не нужен. К тому же, никто не мешает с помощью Dev Tools редактировать и сгенерированный CSS, разницы никакой.

Почему стоит использовать препроцессоры

У меня есть мысли сделать гайд, обширный, масштабный, но, похоже, не совсем то, чего ожидаете — увы, SVN, PHP и прочее слишком далекая от меня тема. Но я внедрял yeoman на существующем проекте Ruby on Rails и получилось, в общем-то. Как-нибудь расскажу.

Почему стоит использовать препроцессоры

Я знаю, но мне удобнее запомнить sm/md/lg (с учетом того, что я использую бутстрап), чем конкретные значения.

Почему стоит использовать препроцессоры

Возможно, это есть в Compass. А так — есть ли смысл?

Почему стоит использовать препроцессоры

Да, если бы CSS развивался, не было препроцессоров.
— Дополнительные инструменты для верстальщиков только в плюс: всякие Grunt облегчают работу с чем угодно — спрайты, минификация и т.п. Разобраться с ними дело нескольких часов, а достоинств — море.
— Синтаксис довольно-таки одинаков, в пределах фантазий авторов — где-то $variable, где-то @variable.
— Синтаксис слишком легкий, чтобы считать, что его знание отягощает и не нужно. На данный момент я не вижу проектов, где не использовался бы хоть какой-нибудь препроцессор.

Куча софта — в общем-то, нет. Базовый проект создается через yeoman и доступны все прелести веб-разработки, существующей 2014 году.

Почему стоит использовать препроцессоры

Обещаю попробовать. Выглядит также мощно, как Sass, но еще чище.

Почему стоит использовать препроцессоры

Нет.
У меня есть миксин responsive, который является оберткой над media-queries.
Вот пример:

.promo {
  padding: 2em;

  @include responsive(sm) {
    padding: 5em;
  }
}

Изначально класс .promo будет с паддингом в 2em, но начиная с sm (ширина окна 768px) — 5em.