A lot of it is philosophical - for the reasons that I dislike Gradle, I dislike SBT, but SBT has the honor of also having historically (and thankfully since cleaned up) esoteric syntax. I simply don't want builds to be allowed to reach the complexity that sbt allows.

I would definitely agree with your point that most build tools aren't easy! I've used maven and grumbled about it, and I'm mostly sold on scripting my build in the same language I'm using anyway, but in my long time on the JVM, it's always been the gradle and sbt projects that end up with inscrutable and hard-to-follow build scripts.

The sbt REPL also regularly breaks existing build scripts by changing how args are passed/parsed, or even how terminal color support works, and I just get sad every time I see a new, unexpected error from one of our CI runs.

Haoyi Li did a great piece on it: https://www.lihaoyi.com/post/SowhatswrongwithSBT.html

Sure; but half the problems apply to other build tools too, not just sbt.

Take for example the point on syntax - is gradles groovy receiver syntax not just as esoteric as operator overloading?

Y does this too isn't really an interesting argument that X doing it is reasonable, I don't think (and my response to your initial question is entirely happy to lump Gradle in with SBT on its "understand-ability" demerits).

Don't get me wrong, my laundry list with SBT is huge - that single point was an example; but I have other points for make, cargo, cabal, stack etc...

My question was what makes SBT uniquely bad when the topic of build tooling comes up that people immediately comment how terrible it is.

For me, it's especially bad with the indirection, and the 3-dimensional cube of settings (I can never remember after all these years which one I want to set, the scope or the configuration or the task...). The complete mystery of how plugins affect the final build configuration.

I even went to a lot of effort to master SBT. I've read through the official docs numerous times, and Josh Suereth's Book https://www.manning.com/books/sbt-in-action, and I still feel like I don't grasp it very well. I'm just not smart enough for SBT.

I think a lot of it is probably just that sbt feels as deep as learning entire programming languages sometimes and that is not something I want in a build tool.