IIUC, the 20% slowdown happens with a build that does nothing, it's just the scons overhead. (Not sure if they replaced the compiler invocations with echo, or if they touched the result files right from Python, for this number. They mentioned both, but I don't remember which one of them resulted in the 20% figure.)
The 20% figure should go down for real world builds.
As much as I don't like programming golang, they did get compilation right. And Scons/ninja/automake/cmake issues just went away.
In C/C++ that means you decided to change 400 translation units.
That's not a problem with the build system at all. That's a problem with how the developers working on the project failed to follow basic best-practices in software development. No build system saves you from the mess you create yourself.
That's the whole point of performance measurement for build systems. The overhead is precisely what counts here.
If you have many source files to recompile, the fraction of time spent in the build system itself is going to quickly drop to almost zero : build-system stuff is generally several orders of magnitude faster than compiler stuff.
So it would make little sense to compare build-system performance on full builds.