Why would I want to modify CFLAGS? Let's see. -fstack-protector, might want that if I want a bit of extra security. -fomit-frame-pointer, might want that if I like a fairly large speedup on x86-32. -g, might want that (particularly if I'm a distributor generating packages with separated debugging information). -D__NO_STRING_INLINES, might want that because the string inlines still slow glibc down more than they speed anything up in my benchmarks. -L and -I, might well need them if some packages are installed in non-standard prefixes. This is a small subset of the reasons I tweak CFLAGS, and most of them are applicable to any random distributor you could name.
Automake gets it *just* right: the CFLAGS, LDFLAGS and so on are propagated correctly, supplemented with makefile-specific flags for those targets where it is necessary, and possibly occasionally overridden for those very very few targets where that is necessary (though this elicits a warning). This is done *by default*: there is no need for the makefile author to hack about with anything or remember to do anything (which nearly all will of course forget).
Automake doesn't take any --with- switches at all: are you thinking of Autoconf? Even *that* only requires them if autodetection fails, in which case you are installing things in nonstandard prefixes and should expect to have to do things by hand.
Oh, and it doesn't require building any kind of 'executable tool' at all, only a portable shell script. The entire *reason* why configure scripts are a shell script is because the distributor / builder needs nothing but a shell and core Unix shell tools: they do *not* need Autoconf or Automake. For scons you need a whole flipping Python installation -- fairly common these days, you think? I wish you were right: Python is by no means ubiquitous. The shell is. Until recently Autoconf's shell requirements were so lax that it actually allowed Solaris 2.6-and-below /bin/sh, which doesn't support shell functions: so we're talking a 1980s shell here!