каким образом это очевидно?

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

тем что гит может работать децентрализовано?

репу склонировать - это заметно больше работы, чем один зип сдёрнуть

далеко не всегда так

ну и мавен может :)

тото у меня CI краснеет когда у clojars проблемы)

так сделай локальный прокси-репо

с тем же успехом можно посоветовать склонировать локально репу)

вроде нексус умеет такое сразу же, но я сам не включал.

ну там вопрос больше, чтобы все прозрачно было, то есть как раз  в режиме прокси.

именно так депсовый гит модуль и работает - нет локального клона с определенным хэшом - пойдем вытягивать из ремоута, если есть - используем то что есть

предельно прозрачно

Так собираем локально всегда?

Или в гит кладём джарники?

в депсах нет понятия “собираем”
это либа для формирования classpaths исключитьельно

Вопрос в том, пересобираем ли мы все зависимости на каждом билде, или ставим какой-то плагин, который складывает билды локально в кэш

В общем, выглядит как переизобретение велосипеда

хотябы https://clojure.org/reference/deps_and_cli#_rationale вот этот абзац стоит прочитать перед тем как делать выводы

депсы *НЕ* билдят зависимости,
депсы кэшируют :mvn-based зависимости так же как maven
гит зависимости кэшируются локально в отдельной директории, но принципиально не отличаются от кэша maven
единственный артефакт работы депсов - это длинная строка classpath в которой перечисленны пути до всех локальных ресурсов, включая ресурсы проекта, гит зависимостей, локальных проектов и пути до всех jar’ок который обычно лежат в $HOME/.m2
этот “артефакт” кэшируется локально для проекта на основе хэша все deps.edn файлов которые учавствовали в его формировании. если что-то измениться (например добавится новая зависимость) кэш инвалидируется и classpath формируется новый