Not everything is C, or GNU/Linux. The example also misses much of the basic functionality that makes GNU autotools amazing.
The major benefit of GNU autotools is that it works well, specially for new platforms and cross compilation. If all you care about is your own system, a simple Makefile will do just fine. And with GNU autotools you can also pick to just use GNU autoconf .. or just GNU automake.
Having generated files in the release tarball is a good practise, why should users have to install a bunch of extra tools just to get PDF of the manual or other non-system specific files? It is not just build scripts all over the place, installing TeX Live just to get a PDF manual of something is super annoying.
Writing your own ./configure that works remotely as something users would expect is non-trivial, and complicated -- we did that 30 years ago before GNU autoconf. There is a reason why we stopped doing that ...
I'd go so far to think that GNU autotools is the most sensible build system out there...
AutoTools are squarely oriented toward C, though.
If you're not using C or C++, you're probably not using AutoTools.
(I think I might have seen someone's purely Python or shell script project using Autoconf, but that was just ridiculously unnecessary.)
> Having generated files in the release tarball is a good practise
Without a doubt, it is a good idea to ship certain generated files in a source code distribution. For instance, if we ship a generated y.tab.c file, the user doesn't have to have a Yacc program (let alone the exact version of the one we would like them to use).
What's not good practice is that anything is different in the release tarball compared to the git commit it was made from.
"Release tarball" itself a configuration management antipattern. We are a good two decades past tarballs now. A tarball should only be a convenience for people who don't need a git clone.
Every generated thing that a downstream user might need should be in version control, and updated whenever its prerequisites change. This is a special exception to the general rule that only primary objects should be in version control. Secondary objects for which downstream users don't have generation tools should also be in version control.