I agree, in particular by the way unity builds can break code that relies on internal linkage to avoid conflicts between symbols. But it's nevertheless a technique that's supported by cmake and can be enabled by flipping a flag.
Yea, honestly these types of numbers really aren't surprising, but usually when you profile a build and dig into why the build perf was so bad to begin with, you generally find stuff like template abuse, bad header organization, and countless other untold sins that were better off fixed anyways.
Chromium once supported unity builds. For me it speeded up builds from 6 hours down to 1 hour 20 minutes on a Windows laptop. And Chromium tries to make their headers reasonable.
Chromium eventually dropped support for such builds. At Google the developers have access to a compilation farm that compiles within like 5 minutes. With such farm unity builds makes things slower as they decrease parallelism. So Google decided not to support them not to deal with very occasional compilation breakage.
Bad header organization is perhaps the gravest yet unspoken cardinal sin of both C and C++ development.
I lost count of the number of times that I had to deal with cyclic dependencies accidentally introduced by someone when they started to add #include without any criteria.
