He again does the typical thing and runs "./configure --prefix=/opt". The configure script runs for a while, then exits with an error which basically translates to "You have an autoconf version which is three weeks old; please upgrade", but this is displayed in the most cryptic manner possible.
This is simply incorrect. If you already have a configure script, then you don't need autoconf installed at all, let alone a particular version of it. autoconf is used for generating the configure script, not running it.
I'm positive that I've seen configure scripts that try to check whether they, themselves, are out of date, and regenerate themselves if so. That's the only time I've seen an error about autoconf version skew.
To be fair, I've only actually seen this on scripts I was writing - never seen it happen to something that passed make dist.
I don't remember exactly (my autoconf/automake-fu has gotten weak these past years), but there's a macro AM_MAINTAINER_MODE that will add --enable/disable-maintainer-mode as an option to your configure script that will determine if rules get added to the final Makefile that will check to see if Makefile.am is newer than Makefile.in or if Makefile.in is newer than Makefile, or if configure.ac is newer than configure (etc.) and then attempt to regenerate them.
I don't quite remember what the default is if you don't include AM_MAINTAINER_MODE in your configure.ac. So yes, you could have indeed seen that happen, but there are ways to make it not happen.
Automake will regenerate and rerun the configure script if configure.ac is newer than configure, which is normally only the case if you're either modifying configure.ac or if the files are packaged incorrectly (and automake makes packaging a release correctly easy).
This is simply incorrect. If you already have a configure script, then you don't need autoconf installed at all, let alone a particular version of it. autoconf is used for generating the configure script, not running it.