Well, cmake is there because people did the same thing to autoconf, so it’s hard to be too sympathetic. Cmake is useful, but also terrible, like most build systems.
The difference I see is that Autotools is mainly useful for handling differences between various Unix variants, which isn't a concern now that commercial Unix isn't really a thing besides Mac OS X. CMake doesn't have the years of arcane knowledge about dozens of Unix variants that Autotools does, but it lets you target Windows using the native tooling as opposed to having to do all your development in Cygwin, and it automatically generates IDE projects so you can use IDE provided tooling like debuggers and profilers. Personally, I think this is a more compelling value proposition than what Autotools offers. Obviously, if you're fine with using a text editor and GDB and for some reason need to target SunOS, SCO UnixWare, 386BSD, A/UX, etc but not Windows, Autotools is great for that use case and you should stick with it.
Pretty much all newer languages massively simplify their build processes by establishing a bunch of common-sense conventions: the output directory is always the same, all *.foo files in a directory are automatically considered source files, the output is identical to the directory name, things like that. They also include proper versioning of dependencies instead of "just assume /usr/include/foo/foo.h is the version we want, yolo".
In principle it's very much possible to do all of this in C or C++, which would massively simplify stuff. But both C and C++ being a "design by committee" affair there will be endless fighting over which conventions to choose so I'm not holding my breath.