I think it's pretty similar to why people use autoconf, Cmake or the like. If you are building something of any real size or complexity, with a lot of 3rd party dependencies, then maintaining makefiles is a serious PITA (and I say that as someone who has used make extensively in their career).
So why not use autoconf or Cmake, then? Well, why would I want to write and maintain scripts in M4 when I can do it in javascript (the language I'm actually programming in)? And again you get into the configuration vs code question. Why should I rely on configurations files and learning how a complex tool works when I can write what I want to do in a scripting language (not-so-coincidentally the language I'm actually programming in)?
In fact, in our shop for various projects we use makefiles, shell scripts, rake and gulp/webpack. It's nice to use a tool that is set up for the idiosynchracies of the language you're programming in. We could make do with just one (probably rake since we do mostly ruby coding), but I can tell you with certainty that it would be more work than the varied ecosystem that we have.
So why not use autoconf or Cmake, then? Well, why would I want to write and maintain scripts in M4 when I can do it in javascript (the language I'm actually programming in)? And again you get into the configuration vs code question. Why should I rely on configurations files and learning how a complex tool works when I can write what I want to do in a scripting language (not-so-coincidentally the language I'm actually programming in)?
In fact, in our shop for various projects we use makefiles, shell scripts, rake and gulp/webpack. It's nice to use a tool that is set up for the idiosynchracies of the language you're programming in. We could make do with just one (probably rake since we do mostly ruby coding), but I can tell you with certainty that it would be more work than the varied ecosystem that we have.