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.