Yes, true, you can construct a machine on which any project you care to run is CPU bound. But meanwhile on my pretty beefy servers compiling a kernel from scratch is very much i/o bound. Maybe if I run it twice in a row after all of the caches have been prepped I can get it to be CPU bound but that's cheating, no? With enough RAM almost anything is CPU bound but that's not the normal situation. A typical laptop has 4 or 8 G of RAM and will rapidly consume all that while doing a kernel compile to the point that it's talking to the disk to a degree that it will slow down to where the CPU's are stalled.

You mean: I've picked my system components in such a way that kernel compiles are not i/o bound. But on an average machine a kernel recompile is very much i/o bound. To the point that people will go out of their way to get large amounts of RAM and very high performance i/o subsystems into their machines. But your average i7/8G run-of-the-mill machine is going to run into the i/o bottleneck pdq. On a 32 or 64G (or even more) RAM box with an NVME drive you probably can get it to be CPU bound. On my 16G laptop with SATA SSD it very much is, the CPU is only utilized about 60% or so.

Yes, all of those are important factor. And playing around with those factors (memory, IO speed etc...etc...) it;s easy to construct a system where CPU could be the limiting factor.

But it's still possible to make a claim that in general, most "in the real world" builds are limited by ram size (especially linking), memory bandwidth not really by CPU. The main reason is really that compilation is not as parallel as one might think.

Compilation used to be much more IO bound in the past. But these days with nvme drives and really aggressive OS file caching (and or ramdisk) IO is less of an issue.

Also note that this changes significantly moving from O2 to O3 where CPU (single thread) performance become more and more important.Same for partial recompilation.