[0] https://gyp.gsrc.io/ [1] https://github.com/waf-project/waf
I'm probably listing the tip of the iceberg as far as network effects. In the Linux/Unix world, autotools is (or at least historically was) what everything and everybody knows how to deal with, and non-autotools is annoyingly nonstandard.
Your gyp link there says for example that its main goal is IDE support; a total non-goal for autotools. Unix/Linux C developers largely do not use IDEs. And the autotools goals probably aren't in gyp's list of priorities. So while they both "build the project" they have pretty different goals.
The autotools goals don't always make sense anymore. For example the historical idea that the shipped tarball would only depend on POSIX sh and not on any other binary made a lot more sense when people were hand-compiling stuff on their HP-UX than it does today where most binaries come from distributions.
If you're building a package mostly for Linux and maybe OS-X-as-Unix-compatible, especially one in C/C++ and open source, autotools probably still has a lot to recommend it.
Autotools was intended to solve the problem of how to give the same tarball of code to a user of SunOS 4, Ultrix, HP-UX 8, and so on, such that each of those users could just unpack the tarball, run ./configure and then make. (Using the make that came with their OS, not CMake, not GNU Make, not gyp and so on).
Some of the requirements don't hold as much any more; you can rely on newer POSIX shell features in a configure script, and GNU make is more widely available and so on, but the basic idea is solid: no requirement for any exotic build system just to get the program running.
It's the implementation that sucks in Autotools. The high level ideas are solid.