There's a lot of weird edge cases that autotools can do absolutely correctly, where cmake went for the simple-and-good-enough approach that simply cannot deal with the edge case at all.
For example: let's say you want to build a program, written in C++; and while building that, you first build a temporary program, also in C++, and run it, which generates part of the primary source code. Parser generators often work this way.
And let's say you want to cross compile your program. You are on an x86 machine, and you want to build your program for arm.
Then during compilation, you first want to build your temporary program *for x86*, and then run it, and afterwards compile the rest of the project *for arm*. If the temporary program is ALSO part of the final build, you need to build it twice, once for arm and once for x86.
If your project needs any libraries to build it, you need to keep careful separate track of x86 libraries and where to find them, and arm libraries and where to find them. Any libraries you need to build your temporary program are x86 libraries, and you probably want to search for them among your system libraries. Any libraries for your final program are arm libraries, and you will find them among "shit I will be shipping". If you confuse the two at any point, shit will break.
cmake cannot do this. It can cross compile, and it can build temporary programs to be used during the build; but not both at the same time. Because cmake only understands one system configuration, one target architecture, one set of libraries, etc. Because it went for the "let's not overcomplicate things" philosophy, which means it cannot solve many tricky problems at all. There are workarounds of course, but they are horrible.
Autotools can totally do this. It can also do a ton of other weird edge cases that cmake can't, but this is one I'm intimately familiar with. Because it's designed to do everything technically right, with no compromises.