Did your 100-track Cubase project run out of CPU power? If not then it proves the point that you're hitting other bottlenecks first.
As stated multiple times, here and on previous forum threads...Cubase was taking double the CPU % compared to other daws and was not able to play 100 tracks, it ran out of the ability to play the project somewhere around 50-70 tracks. You say there is no correlation, but I think there is. I personally did not have time to do a more rigorous test where I attempted to get each DAW to crap out and see how many tracks each one could do before it started to crap out. Cubase crapped out around 50-70 tracks...with the CPU cranked to double the others.
I can certainly make a project that'll cause dropouts. But I can't get CPU usage anywhere near 100% when those dropouts start to occur. The single largest factor for dropouts is audio buffer size, and that drives real-time performance requirements, not CPU performance requirements.
A larger buffer size allows the DAW more breathing room to get the CPU crunching the DSP while multi tasking..until it can fill the buffer. if the buffer is small, then it should not take the CPU very long at all to fill the buffer, yet..that is when we get drop outs. That is because of the multi-tasking nature of the computer. A computer will almost never run at 100% cpu...but that doesn't mean the CPU inefficiency is irrelevant. Every time a process gets a slice of time to crunch some numbers, it needs to be efficient, If it gets enough slices of time then it can fill the audio buffer in time to send it. If it doesn't complete the task, then the audio buffer gets sent partially filled....ie dropout. With a smaller buffer, the buffer is smaller, but so is the length of time that the computer has to multi-task with various processes...so there is more possibility that the DAW will not get enough time allocated to it to fill that small buffer.
CPU efficiency absolutely matters, and the numbers posted by AshMusic are not irrelevant. Both aspects are relevant and interesting.
generally we are only interested in low latency performance while tracking in parts, and that is usually on so called "live" channels that generally will be using a single core of the computer. The computer can still be showing way less than 100% cpu utilization, yet that single core simply can't keep up with whatever time the OS allocates to the DAW for using the CPU, fast enough to fill the buffer during one Process block of time. Then you get drop out.
The hardware generally works like a robot, it takes the buffer and plays it in perfect real time. The job of filling the buffer belongs to the DAW, using the CPU.
However, the CPU gets shared by numerous processes in the OS and so that is why it can't always get it done, ESPECIALLY if the DAW is doing inefficient crap.
There is absolutely a correlation.