Could you provide more details on what you want to override with 1.? Does anyone really care about 2.? When is 3. a problem?

ad 2) it makes easy to add new file by one line change. Other thing is with keeping the same format everywhere. Generally importance is the same as with keeping the same style of C code indentation. As our brain is perfectly suited to catch any broken patterns keeping the same style everywhere allows easier catch points where (in this case automake) code is wrong.
ad 1)

-libzbxdbcache_a_CFLAGS = -I@top_srcdir@/src/zabbix_server/ -I@top_srcdir@/src/libs/zbxalgo
+libzbxdbcache_a_CFLAGS = \
+          -I$(top_srcdir)/src/zabbix_server \
+          -I$(top_srcdir)/src/libs/zbxalgo

Without this is not possible to specify top_srcdir after running configure because it will be hardcoded at the end of configure execution, or:

-       -DSYSCONFDIR="\"@sysconfdir@\"" \
-       -DLIBDIR="\"@libdir@\""
+       -DSYSCONFDIR="\"$(sysconfdir)\"" \
+       -DLIBDIR="\"$(libdir)\""

This will break for example overwriting sysconfdir on "make test sysconfdir=/my/cfg" where temporary new object file will be created, linked and used on tests.
In other places is not needed m4 macroing because automake automatically generates in Makefile.in files lines with variables:
FOO = @FOO@ so all what is needed in Makefile.am is use those variables straight

Generally using @FOO@ macroing in Makefile.am is kind bad habit. Usually it does not harm but when project grows/extends and for example sophisticated test (before install) will be added such things makes whole automake broken or it may be source of some confusion.
ad 3)

tar xzf zabbix-<version>.tar.gz
mkdir tmp_builddir
cd tmp_builddir
../zabbix-<version>/configure <params>
make

Above will keep zabbix-<version>/ clean and all temporary files, Makefile, object files will go to tmp_builddir/.
Original source tree can be even on RO storage. It is very useful for example when you need perform test builds with different "configure <params>" and/or when you want to keep archived for the record all files used during build.
Automake automatically generated all static libraries (and other build stage files as well) in $(top_builddir) and some linker *_LDADD have hard coded $(top_srcdir) such build will fail.

Sorry .. may I ask for update?

I am not in charge of making decisions which features are implemented, which bugs get fixed or which patches to review and test. Zabbix developers are few and they are overloaded. Sometimes I spend my free time to have a glance at user requests, problems, patches, etc. But at these moments I am usually an ordinary community member like you. Sorry.

Seems it is a problem with accepting my fixes.
Will try another approach by sending only patches against one issue.
Here are patches replacing use $(top_srcdir) by $(top_builddir) for trunk, 3.2 and 3.0.

Uploaded s/top_srcdir/top_builddir/ trunk patch.

Updated patch against trunk branch.

I am trying to repeat it with the latest trunk and it fails with and without top_srcdir patch:

tar xzf zabbix-3.4.0alpha1.tar.gz
mkdir tmp_builddir
cd tmp_builddir
../zabbix-3.4.0alpha1/configure --enable-server --with-mysql
make

Error running make:

make[1]: Entering directory '/tmp/tmp_builddir/src'
Making all in libs
make[2]: Entering directory '/tmp/tmp_builddir/src/libs'
Making all in zbxcrypto
make[3]: Entering directory '/tmp/tmp_builddir/src/libs/zbxcrypto'
gcc -DHAVE_CONFIG_H -I. -I../../../../zabbix-3.4.0alpha1/src/libs/zbxcrypto -I../../../include     -g -O2  -MT libzbxcrypto_a-md5.o -MD -MP -MF .deps/libzbxcrypto_a-md5.Tpo -c -o libzbxcrypto_a-md5.o `test -f 'md5.c' || echo '../../../../zabbix-3.4.0alpha1/src/libs/zbxcrypto/'`md5.c
../../../../zabbix-3.4.0alpha1/src/libs/zbxcrypto/md5.c:54:20: fatal error: common.h: No such file or directory
compilation terminated.

I suspect it's something to do with include path that possibly also should be adjusted somewhere.

Just found what exactly was missing in cinfigure.ac to make this patch working.
This patch is against trunk so it is ready to evaluate/test and possible commit.
later will try to prepare the same patches for 3.2 and 3.0 branches.

FYI: In next few hours will try to upload updated version of that patch.

Just uploaded latest version of that patch for 4.2.7.

Fixed in:

• 5.0.0alpha1 (master) dcf7a68fb21