Венец эволюции CSS-in-JS уже здесь: полностью типизированные стили без рантайма в vanilla-extract

Ну не знаю как вы, а мне вполне нравится. Из преимуществ — максимальная гибкость, при этом никакой расплаты за неё в рантайме.

При единых выходных файлах действительно расплата будет не в рантайме, но в билдтайме. Стилевые TS файлы нагружают парсер IDE и общий лоадер для ts-файлов, что приведет к деградации скорости сборки, поиска по проекту, подсветки типов, линтера. Конечно, работа с CSS тоже не бесплатна, но она параллелится, а тут все в большой куче получается.

Sprinkles посмотрел — это переизобретенные mixins, в которых давно реализовано то же самое:

.class { @include paddingX(10px); }
.class { display: inline; @mobile { display: block; } }
@mobile { .class { display: block; } } // предпочтительней этот вариант, чем в каждом отдельном классе прописывать адаптивное поведение
.class { padding: $gap-small; }
.class { padding: var(--gap-small); }

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

"Более удобная композиция класснеймов" — спорно, я не вижу ни одной неудобной строчки в таком варианте:

  get wrapperClassName() {
    const { className, inputConfig } = this.props;

    return cn({
      [styles.inputWrapper]: true,
      [styles.focused]: inputConfig.isFocused,
      [styles.disabled]: inputConfig.disabled,
      [styles.hasValue]: inputConfig.value !== '',
      [styles.hasErrors]: inputConfig.errors.length > 0,
      [styles.hasIcon]: Boolean(inputConfig.icon),
      [className]: Boolean(className),
    });
  }

В CSS файле все удобно разложено и красиво отформатировано. Приоритет стилей определяется порядком их следования в стилевом файле и усиленной специфичностью. В css-in-js в большинстве реализаций описание подобного превратилось бы в ад, как и стилевой файл.

По поводу вербозности — каким бы ни был лаконичным DSL, он максимум что сможет сделать — приблизиться к композиционному подходу с миксинами, при этом сохранятся все вот эти обертки типа createAtomicStyles, createAtomsFn, экспорты, нетипизированные значения без подсказок от IDE и соответственно с большой вероятностью опечаток, кастомное структурирование типа conditions, defaultCondition, properties. Все это абсолютно лишний бойлерплейт — через устоявшиеся подходы все делается удобней и не нужно никакого дополнительного обучения для разработчиков, достаточно изучить файлы с константами и миксинами при переходе в новый проект.