It's a stretch to say every programmer should know about this stuff when most apps aren't I/O limited. For my purposes, I care that SSDs are fast, not about the underlying architecture of the NAND, page sizes, or drive controller. I also know absolutely zilch about the inner-workings of the Linux kernel and don't plan on reading a book about it.
The nice thing about so much division of interest in the engineering field is that you don't always need to know everything about what's going on under the hood to use a technology to build other cool stuff. Only in specific situations is that knowledge really necessary.
Is that the case? You hear time and time again that most modern web applications in particular are I/O-bound. I suppose that depending on the particular case the I/O device in question may not be a local disk but that doesn't categorically change it.
As a web host that focuses on "scale" type sites (alexa top 100), you are absolutely correct.
Out of the 3,000+ servers we've managed, a very small handful are CPU bound. I/O (disk access) is almost universally the issue we work with client developers to fix, and it's extremely rare to run into anything else.
That said, I/O bound apps manifest themselves in many ways. One app could be doing something stupid with serving files, another app may have ridiculous SQL queries, another may be using the wrong technology for a given problem, etc. The universal truth though is that the CPU you toss into a server is almost inconsequential, but your RAM (read: caching) and disk configurations matter quite a bit.
If network-bound apps are rare, then you believe that mobile apps and web apps are rare. Both are, combined, likely to make most other app types seem rare.
You seem to be confusing client and server. When people say I/O-bound or CPU-bound they usually refer to servers.
And most clients aren't network-bound either. They are server-bound (i.e. they spend more time waiting for the server to create a response than for the network to transfer it).
No, I'm not confusing anything. I can see why you would believe that, based on what I assume you made as inferences.
There are plenty of mobile and web apps that are network bound in this day and age. Many games, for example. That's just the obvious choice of example.
games are more sensitive to network latency, not throughput.
The phrase "I/O bound" is typically used in the context of throughput limitations, not latency. The issue of network latency is more complex than simply the network level as it involves the whole software stack in the equation.
The nice thing about so much division of interest in the engineering field is that you don't always need to know everything about what's going on under the hood to use a technology to build other cool stuff. Only in specific situations is that knowledge really necessary.