The general principle of allowing $builddir and $srcdir to differ
is _usually_ good. (E.g. see bug 83.) For instance a site with multiple
architectures can have many $builddir all mutually independent,
maintained from a common, effectively read-only, $srcdir.
But I don't think that principle applies to "autogen.sh", whose job is much
earlier in the chain, building the "configure" script etc. in the first place.
Indeed, the whole purpose of "configure" is to be common across everything.
The typical end-site will run "./configure" on whatever they have, and it is
only AFTER configure, not before, that system-dependencies enter the picture.
By far the primary purpose of autogen.sh is to assist the package maintainers:
the Samba team, and the relatively few folk who diddle with ".in" files.
The typical "grab the 'tar' file" site will simply use the common "configure",
itself generated by those package maintainers.
So, despite my being a strong advocate of clear separation of $srcdir from
possibly multiple $builddir, I think that "autogen.sh" is the exception
to that good general rule.
(There may be a residual counter-argument in favour of autogen.sh separation
(of $builddir and $srcdir) for those "pre-configure" folk who wish to test
different versions of autoconf itself...)
Hope that helps the thought-process!