slack-gradle-plugin VS idiomatic-gradle

You can go very far with this approach. Slack has a single standardised plugin that they apply to all their android projects which exposes some high level config DSLs for those projects to configure which build features they want/need https://github.com/slackhq/slack-gradle-plugin

slackhq/slack-gradle-plugin is also pretty nice as a reference for really streamlined projects

As for the Gradle setup, I've always wanted to remove as much boilerplate in the Gradle scripts as possible, and custom Gradle plugins is one of the solutions I found. There is still some work to be done in terms of cleaning it up, although I am quite pleased with how it turned out anyway. The slack gradle plugin is full of great info about how to create your custom Gradle plugins to centralize Gradle configuration into a easy-to-use API.

You should look into how https://github.com/jjohannes/idiomatic-gradle and similar projects handle it (nowinandroid has a good set up as well).

And finally, look at the idiomatic gradle repo. There is also a free video series that goes with this Understanding Gradle – Video Series. There are lots of bad practices in gradle that will slow your builds down, like using allProjects {}

For a long-lived (aka - something you'll maintain and may grow) multi-module project, I'd suggest following the idiomatic gradle structure. But there's a lot to unpack there, so it may not be the ideal thing to start with. Once you grok it though, that structure scales incredibly well, and allows you to avoid duplicating lots of configuration (via 'precompiled script plugins', largely in the build-logic project in that repo), and make use of build caching without having to modify things.

I'd suggest getting rid of buildSrc, and just using build composition. I mentioned in another response, but check out https://github.com/jjohannes/idiomatic-gradle for how to use precompiled script plugins that are connected to the project via includedBuilds. The only issues I've had with this are generally resolved by just running the sub-build independently to resolve any caching issues in the 'primary' build. A simple gradlew build --settings-file ./build-logic/settings.gradle.kts run will generally resolve that, and that issue seems largely because of the 'root' build being a peer or anscestor of the included build (due to legacy structure of the project, an issue the linked example repo does not have).