Flying

На StackOverflow есть прекрасный ответ, описывающий причину и решение (точнее хак, но он помогает).

Если вкратце - добавьте к вашей анимации микроскопический rotate:

@keyframes animStar {
	from {
		transform: translateY(0) rotate(0.05deg);
	}
	to {
		transform: translateY(-200vh) rotate(0.05deg);
	}
} ;

UPD: Вот bugreport (до сих по откытый) по этому поводу и объясение от разработчика почему rotate() помогает.

Общие CSS классы можно использовать если вы контролируете установку этих CSS классов, ведь это делается в HTML. Естественно в этом случае объём результирующего CSS кода будет меньше, но в сложных случаях логика расстановки CSS классов может быть не самой тривиальное.

В отличие от них mixin'ы влияют на генерируемый CSS. Кода в итоге скорее всего будет больше, но он будет более изолированным и менее будет зависеть от управления HTML. В плане производительности, если подходить с умом и не строить многоуровневые сложные селекторы без надобности - особых проблем быть не должно.

Также не стоит забывать о ещё одном способе горизонтального расширения - placeholder'ах. Их использование позволяет сэкономить на объёме CSS кода за счёт исключения дублирования, но может иметь не самые очевидные последствия без понимания того что именно стоит за этой абстракцией.

selector-parse(&), детали см. в документации.

Вложен внутри селектора - да, может, но внешние по отношению к нему селекторы будут добавляться ко всем селекторам, использующим placeholder.
Вложен внутри mixin'а - да, может.
Вложен внутри @media запроса - да, может, но @media запрос будет также применяться. Также такой placeholder не может быть использован внутри другого @media - это приведёт к ошибке.

Ответы на все эти вопросы довольно очевидны если помнить что placeholder - это по сути просто CSS селектор с возможностью дописывания к нему новых селекторов через запятую.

Поиграться можно здесь.

1. dart-sass - reference implementation языка т.е. является образцом того как должен работать язык. node-sass binding libsass (реализации спецификации языка на C++) к node.js.
   
   dart-sass содержит в себе все последние фичи языка, к примеру там уже есть поддержка sass modules, libsass отстаёт, а node-sass отстаёт от libsass. За пруфами - сюда и сюда
   
2. libsass производительнее, местами - существенно. К примеру в моих тестах интенсивная работа с sass maps в libsass примерно в 10 раз быстрее чем в dart sass. Насчёт микросекунд - у меня есть проекты которые по 15-20 секунд компилируют только стили на node-sass, на dart-sass всё намного медленнее
   
3. Приведённые ссылки - сравнение тёплого с мягким. Есть реализации языков, а есть плагины для их подключения к различным сборщикам. sass - сама реализация языка, gulp-sass - binding для Gulp, sass-loader - binding для Webpack
   

Ваша задача по сути сводится к динамическому обращению к переменным. Sass так не умеет. Для реализации вам необходимо сменить структуру данных и использовать maps.

Т.е. ваш код мог бы выглядеть как-то так:

$vars: (
  1 : #333,
  5 : #111,
  100 : #222,
);

@mixin div-color($id) {
  @if (map-has-key($vars, $id)) {
    color: map-get($vars, $id);
  }
}

Посмотреть в действии можно на Sassmeister.

Использую по возможности всё что есть в Sass и хотелось бы видеть в нём больше. Активно использую и переменные и миксины и функции и placeholder'ы и list'ы и map'ы и т.п. Многие практические задачи намного легче решаются через препроцессор, те же CSS variables ни разу не замена.

Конечно для того чтобы код не превратился в кровавое месиво - необходимо соблюдать правила, но это справедливо и для любого другого языка программирования. Да и без использования препроцессоров я видел огромное количество write only css который невозможно нормально поддерживать.

Вопрос поддерживаемости - он не лежит в плоскости используемого инструмента, а является следствием наличия или отсутствия архитектуры в проекте. Если макеты дизайнера сделаны в стиле "я так вижу", без внутренней логики, если всё это сверстал верстальщик по принципу "что вижу - то и сверстал" - то никакое наличие или отсутствие препроцессора на поддерживаемость кода не повлияет.

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

Причина вашей проблемы в непонимании того как работает псевдо-класс :first-of-type. На Stack Overflow есть пара очень хороших объяснений этого, стоит ознакомиться (раз, два).

Ключевым моментом для понимания должен стать тот факт что в контексте HTML понятие "element type" эквивалентно имени тега. Таким образом ваше ожидание что .services-block:first-of-type означает "первый элемент с классом services-block" ложно и это приводит к неработающему селектору. В реальности этот селектор читается как "любой подэлемент текущего элемента, имеющий класс services-block и при этом являющийся первым элементом с таким именем тега среди всех имеющихся". Слегка контр-интуитивно, да, но уж как есть.

Вашу задачу можно решить если вы вспомните что div - не единственный элемент в HTML и начнёте использовать также и другие элементы. В вашем примере для div.basic-title и div.services-block_title явно лучше подходят какие-то из элементов заголовка, а структура из div.services-block_item и подэлементов - это явно dl/dt/dtt

Простая замена заголовка на какой-либо Hx элемент позволит использовать селектор

.container > div.services-container:first-of-type > .services-block:first-child

.

Также можно ничего не менять, тогда селектор получится несколько более жёстким:

.container > .basic-title + .services-container > .services-block:first-child

В целом всё очень просто:

@each $query in $queries {
    @media (max-width: #{$query}) {
        @for $i from 1 through 6 {
            h#{$i} {
              font-size: nth($sizes, $i);
            }
        }
    }
}

Однако лучше хранить размеры в map'е, это позволит упростить код:

$sizes: (
  h6: $fzh6, 
  h5: $fzh5, 
  h4: $fzh4, 
  h3: $fzh3, 
  h2: $fzh2, 
  h1: $fzh1
);

@each $query in $queries {
    @media (max-width: #{$query}) {
        @each $tag, $size in $sizes {
            #{$tag} {
              font-size: $size;
            }
        }
    }
}

На самом деле ваш пример почти корректен, только чуть доработать:

@mixin last-childs {
    @for $i from 7 through 1 {
        &:nth-last-child(#{$i}) {
           margin-left: 40px - 5px * ($i - 1);
        }
    }
}