I think the right thing to optimise for is input latency.
As to why you shouldn’t just silence all that noisy spam output, you never know when you might need it to diagnose a weird build error.
Sure, it would be great if the build system always produced nice concise output with exactly the error messages you need, but that’s not always realistic. A big bunch of spam that you can dig into if you need to is almost as good -- as long as it doesn’t slow you down.
Edit to add: I guess another approach is to redirect spammy output to a file instead of the terminal. But then I have to know in advance which commands are going to be noisy, and it introduces another workflow (maybe the error message you need is right at the end of the output, but now it’s tucked away in a file instead of right there in your terminal).
Just make the terminal fast at handling large output. No reason that should make it harder to have good input latency too.
Surprisingly few terminals, when suddenly faced with a million new lines of text, decide "hey, let's just draw the last screen of output, I don't need to draw each and every line and then move the existing text upwards by a row"
Some applications output a few lines, then many MBs of "\rcurrent progress: xx.xxx%" that constantly overwrites itself.
Rendering is just not linear.
They would care if they knew it would also block their program doing the output...
Compression yes
It can pipe many megabytes of text output per second on relatively slow channels (`ssh -vv` prints the total data transfer when you close the connection), as long as it's not encrypted or unable to be compressed for some other reason (which is pretty rare for text output).
Scrolling very large files in vim becomes much faster, for example.
It is great for unstable / slow links and pressing ctrl+c works immediately which is nice.