In my opinion, when possible, it is better to stuck to standards, and use just a Makefile for POSIX targets (it allows context detection) and a custom scripts or Makefiles for exotic platforms.
In the end, the reason for e.g. Autoconf, is the mess of different non-standard crazy stuff. Why not to agree a build standard base, at least for the C language and library handling?
Speaking as someone who was a system administrator responsible for compiling a large number of packages across a wide variety of platforms (let's see, SunOS, Solaris, AIX, Irix, Linux, and HP-UX, all at different versions at different times) through the '90s and early 2000s, autoconf made things much, much easier.
It doesn't help the developers any; each individual difference has to be identified by the developer. (My biggest complaint isn't that it's written in m4, but that there's no comprehensive list of what I need to do with it. That information makes up the m4 tests, but there was no documentation.)
Don't like libtool? http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html
I think the key phenomenon here is that software is non-portable by default, and portable through effort. If your problem is that the Linux code should use epoll() and the BSD code should use kqueue(), but OS X has quirks in its kqueue() implementation, and you need to fall back to poll() otherwise, autoconf will help... slightly. Then you need Sys V init scripts, or rc scripts, or launchd scripts, or... who even knows, unless you actually convince someone to port your project to that system.
So, you already have people testing and fixing bugs on other platforms, but now you tell them that they need to also learn M4 so they can write an Autoconf macro to test for some... thing... that you need which doesn't have a standard test. I'm not convinced that this makes my life any better.
Whether or not you like Autoconf, however, you have to agree that libtool has serious problems.