For example, you may have a few frameworks that can be built in parallel, followed by a few tools that can be built in parallel, but the frameworks always need to be built before the tools.
In this case, you could have a Frameworks/ and Tools/ subdirectories, built using serial-subdirectories.make so that they are built in that order. Inside Frameworks/ you then have a GNUmakefile that uses parallel-subdirectories.make to build a number of frameworks in parallel (each of them in its own subdirectory), and similarly in Tools/ to build the tools in parallel.
The advantage of parallelizing the build of entire directories might not be apparent simply because your CPU might not support enough concurrency to do more than a few things in parallel. But if you simply organize your directory structure and use parallel-subdirectories.make and serial-subdirectories.make in a way that makes sense, you'll get the full benefit of more parallel-capable CPUs as soon as you get them. Your build will scale really well when you add CPUs and cores.
Moreover, when you parallelize building entire directories you not only parallelize the compilation steps, but all the other ones; linking and even before-all:: and after-all:: rules.
For example, if you have in one directory a before-all:: rule which takes 10 seconds to run, since it is executed serially it may prevent anything else from running for these 10 seconds. For 10 seconds all your other CPUs or cores might be sitting idle. But if you parallelize the build of that directory with the build of another directory, even during these 10 seconds, the other CPUs or cores might still be busy building things in the other directory.