Back in the day when the GPLv2 was drafted the "scripts to control compilation and installation" referred to things like the Makefile of a single package on a Unix workstation where you had full access a shell and a compiler and the package was built and installed on that machine.
These days firmwares with tons of free software are built and installed on millions of devices. How these firmwares are built is often a non-trivial process. You need to set up a cross compilation environment (smart people go for standard solutions of course, but there are tons of homebrew things out there), different devices have different layouts of flash or the way firmware upgrades are assembled, and so on. Without the information in the build system, or the build system itself, it is impossible to recreate the firmware, sometimes not even the individual components. So from a software freedom standpoint having the build system, plus the configuration to build the software makes a lot of sense.
Of course, whether or not this could be legally enforced is another question. The argument can certainly be made that a firmware is "mere aggregation" and not a derivative work.
The most valuable part from the build scripts are not the scripts, but the information about things like firmware layouts and configuration options, which I know developers extract and then merge upstream into projects with proper build systems. When I talk to companies I always suggest to ditch the homebrew scripts and go for standard solutions, which make a lot of compliance questions a lot easier.