So, i'm in the process of moving a bunch of "script-y" type things in our app's build.gradle.kts into the build-logic area. There's some obvious candidates for moving, for instance we have multiple flavors of our application for different partners and they all have their own settings for certain things like manifest placeholders, etc... So rather than script things like that, i've moved to a plugin that uses an extension on the flavor. But my question is whether there's some guidance on what should and shouldn't be in build-logic? For now i've stuck to things that have imperative code associated with them so that i can move towards a more declarative build file (can't want for DCL to be a real fully released thing).

I don't know of any guidance but I think your idea is correct: strive to raise the abstraction level of the build script, make it declarative, and hide the lower-level, boring, imperative stuff in the build logic. The tradeoff that I see is that while splitting things this way enables you to simplify the build script and/or make it more powerful, at the same time you will probably make the build logic more complicated and more difficult to understand.

Having the imperative things in build logic code instead of build scripts is a great start, this makes for more idiomatic builds. Additionally, you can move things that you do repeatedly in multiple build scripts to build logic code and have a higher abstraction level in the build script. In the extreme it is not uncommon that a build script only declares one to a few own convention plugins and adds some dependencies.