I'd be unhappy with a build system that required me to write makefiles in C because C is a bad language for writing makefiles in. However, I note that makefiles are themselves little more than dependencies tied to shell script fragments, so clearly the shell and make are relatively tightly associated (indeed, make knows internally what characters are common shell metacharacters, and stuff like that). configure scripts can in any case accept C fragments too (and Pascal fragments, C++ fragments and the like). They are used where they are suitable, i.e. when trying to figure out properties of the compilation environment.
What I was trying to point out is that the nonportability of shell script is a bad argument against autoconf if you use any other shell script in your source tree, because you are just as likely to introduce nonportabilities there as in the configure.ac (and they would be just as hard to detect). The portability or otherwise of C is irrelevant to this argument: your objection is a non sequitur.
configure scripts depend on the shell environment in any case, so allowing you to introduce your own shell fragments introduces no new dependencies, which was very important to the Autoconf designers. (Again, the manual *says* all this. This is not secret hidden knowledge.)