Итак. Я немного проебался и не уточнил всю инфу, благо в коментах меня поправили. Более того, слона то я и не заменил, оказывается у нас на проекте оно давно используется.

Значится, Gradle за последние несколько релизов сделал серьезный шаг вперед и научился кешировать конфигурацию.
Причем для кеширования конфигурации, даже есть две опции. Обе кстати до сих пор экспериментальные, но вроде как работают нормально:

1️⃣ org.gradle.unsafe.configuration-cache. Самая рекомендуемая опция, все довольно очевидно, если input для конфигурации не меняется, т.е не меняются скрипты или другие входные данные все будет закешированно и повторно запускаться не будет. Работает хорошо, но для настройки есть потешные параметры вроде того, сколько ошибок мы можем выдержать прежде чем кэш упадает.

2️⃣ org.gradle.configureondemand. Не совсем кеширование, а скорее мы говорим Gradle, давайка ты не будешь конфигурацию запускать на всем проекте, а только вот на нужных мне модулях. Это будет работать только в том случае, если у вас разработка ведется в небольших sample проектах, т.е когда вы не собираете большой проект со всеми модулями, а только необходимые вам фичи.

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

Однако несмотря на то, что Gradle таки научился сохранять кэш проблема с инкрементацией остается актуальной. В примере с кешированием конфигурации, стоит поменять один скрипт, у вас перезапустится вся конфигурация. Это естестенно приводит к тому, что стоит вам переключится на другую ветку, с большой долей вероятности вы опять будете ждать конфигурацию