If someone tells me it doesn't work on, say, Solaris, my next step will be to convert it to autoconf. The essential complexity is still there.
There is no point in testing for things for decades-old systems if you don't have any users on such installations.
The Autotools approach isn't overkill; it's overshoot. To declare something overkill, it has to solve the problem fully. Most of the Autotools-build packages in a GNU/Linux distro will not work on ancient systems, so they don't actually kill that problem. Even if the configure script actually runs through (unlikely), it will fail to detect things that the programs need. There won't be any fallbacks and so things won't build. If things happen to build, they might not run properly.
Porting requires work. You don't develop on system Y and assume it works for users of system X because you're on Autoconf. To call system X supported, you get a system X box with a development environment and port X. That is why, subsequently, the configure script works on system X flawlessly and everything builds.
Only test for the features you actually care about, though. And at this point, it's perfectly fine for a new project to assume some baselines like POSIX-1996 and even C99 (unless you're targeting Windows...).
You could have a canned set of files, one per platform, containing some canned settings of variables. (The Pine e-mail program was a good example of this; its Alpine successor uses Autoconf.)
If you are porting to a new system, you have to guess which of the existing canned configurations is the closest one that will work and use it as a template.
Since there is no logic to detect if any of the features related to the configuration variables is actually present and in what form, it's just guesswork. Okay, it doesn't build. Now which of the relevant variables in the canned config is related to that breakage?
For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --- this is not just assumed from _FILE_OFFSET_BITS=64.
New developments in POSIX have created a fuzzy landscape which resembles some of the confusion in 1990 Unixes. This platform needs _POSIX_C_SOURCE=<at least such>, another has the same thing under _XOPEN_SOURCE. Apple won't declare anything useful to you without -D_DARWIN_SOURCE.
Some platform needed __EXTENSIONS__ to declare struct winsize. I don't remember which one, but my script detects that.
Systems are not becoming more alike. Even when it comes to standard stuff, they vary in their conformance to POSIX, and in how they declare identifiers and the exact headers that have to be included and such.