This is exactly my biggest problem with some other tools: That they try to automate everything with lots of "magic". And this does not lead to clearly understandable, well-defined systems which are maintainable in the long run. If one is debugging hard problems, for example in multi-threaded code with deadlocks, what happens is that one needs to get a very clear understanding of what a certain piece of code does. The same is the case for debugging build systems. In the end, the build system needs to deliver an efficient, clearly understandable,
unambiguous definition of how the software is constructed from the different pieces.
Some systems seem to try to absolutely minimize the amount of configuration code which is required for simple things, using "automatic configuration". If this is for clearly defined things like configuring a library to be static, this is fine. But when it becomes unclear and ambiguous what actually happens, or, worse, when you can't say what versions of dependencies are actually used, this is too much magic. And also when one needs twenty minutes or more to figure out how to switch on address sanitizer, or use a specific language standard. And this becomes worse when the configuration becomes more automagical with each iteration of the build software and the constructs and semantics start to depend on which version of the tool one is using.
autotools has the advantage that these things are quite explicit, and the configuration interface is very stable, and this helps to understand and maintain a system.