Projects like CMake, SCons, and Jam try to obviate the need to write make files, but they treat the configuration step as an afterthought.
To compensate, the replacement just needs to offer better facilities for triggering installs of the missing dependencies. That's basically the path taken by modern languages (Go, Python, Ruby, Node… gnome's jh_build is part of the same trend): they have tools to fetch source dependencies from the network, to install in custom prefixes that don't require root, to create isolated prefixes so that multiple versions can be installed in parallel, to freeze known-good versions of the dependency graph.
But those little knobs so you can build your own customised version with decals and your own red spoiler? No one will miss them.
However, there are also optional dependencies. SoX can use FFTW to make spectrograms, but it's optional. You can use x264 from ffmpeg but it's not necessary. Emacs will build with GTK 2 support, GTK 3 support, or neither; and it will use whatever PNG/JPEG/XML/etc libraries happen to be installed but doesn't care if they're not present. GCC will use Graphite whet available. A few programs will happily play audio through libao or Core Audio or ALSA. There's combinatorial complexity there in theory, but it's not hard to isolate optional dependencies in practice, most of the time.
And suppose you want to use some feature available on new Linux kernels. It's just easier to write an autoconf test rather than try to come up with some convoluted preprocessor test.
There are also important knobs to tune: look at LibGMP, ATLAS, or FFTW for examples. Old PowerPC Macs could run 64-bit code if you asked but ran 32-bit by default, so you'd compile GMP for 64-bit and get a huge performance boost.
And some options are only useful to developers, like enabling -Werror (which should never be enabled by default in a source release). The configuration step bakes these options into the makefile so you can still just type "make".
You have a good point about hard failing when dependencies aren't present, and the configuration step allows you to fail early and provide an intelligent error message.
I'm not convinced that eliminating a configuration step improves reliability. Just think of how dirt-common autoconf scripts are, in spite of how much of a pain autoconf is to learn.
Not saying autoconf is awesome (I curse it on a regular basis), but the configure step itself is worth keeping around.