Well, yes, that's a bad way to measure performance. But when I compile something, it's because I want feedback from the compiler and static analyzer about the program I just wrote. I have a half-dozen parts of the program in short-term memory which I want to consider when seeing the output or the program behavior. If it takes five minutes to compile code, then my short-term memory will be filled with something else by then, like the weather, chores I'm putting off at home, or whatever.

So if you measure how long it takes for engineers/developers to get feedback, you're really measuring how good their tools are, which is a half-decent proxy for engineer performance.

It's more like reading reddit, when you're waiting for a heavy computation, you're not exploring results, tuning the algorithm or anything. You're just stuck on your tracks by a stupid machine. If anything, you'll be conservative in your use of the slow algorithm, because you don't want to lose another half day. You can't fiddle. Even if you try to be productive reading something smart in the mean time, you'll be interrupted by the end of the computation, and you'll be completely out of context when analyzing the results.

(Note that it's the same when testing takes a long time, coincidentally, the same company had a long running product and 80 minute test cycle, so everybody was paid to take coffee)