For lots of data sets, and that includes many so-called I/O-bound datasets. Don't forget that a lot of I/O is very fast nowadays: if you're reading 100's of MB from the disk a second, you can't spend much time on the CPU processing each byte before the CPU becomes the bottle - you have on the order of 10-100 of clock cycles a byte, no more. Simple things like decoding utf-8 and checksumming can take a significant portion of this time, and that's before you're parsing anything. (Hence stuff like protocol buffers...)
If you're trying to make a fast program you obviously avoid too much expensive I/O. You can't avoid some latency, but you can often avoid a lot, and cache a lot, and place the rest closer to the consumer.
When you say I/O dominated, are you sure you don't mean: interactive website? Because I think the real saving grace there is that's it's OK for websites to be very slow - from the perspective of a CPU. It's not that the I/O needs to take a lot of time, it's that you have 100ms (and that's before ajax and relatives, which can hide even more latency), and you just don't need a lot of optimization to get into that restriction. And once you have, the difference between 100ms and 1ns just doesn't matter nearly as much; so sure, then you start to accept very inefficient I/O setups even though much more efficient ones could be readily available.