>> You especially need to consider typical computer usage involves using more than one application at a time. There's a tragedy of the commons issue

These resources include:

  - disk/ssd/long term memory
  - RAM/System memory
  - Cache
  
  BUT ALSO
  - Registers
  - CPU Cores
  - Busses/Lanes/Bandwith
  - Locks
  - Network

My point is that I/O only dominates when you're actually acting efficiently. This is dominating in the case of measuring a single operating program.

You're forgetting that when multiple programs are running that there's a lot more going on. There's a lot more communication going on too. The caches are super tiny and in high competition. To handle interlacing all those instructions. Even a program's niceness can dramatically change total performance. This is especially true when we're talking about unoptimized programs because all those little things that the OS has to manage pile up.

Get out your computer architecture book and do a skim to refresh. Even Knuth's Book (s)[1] discuss much of this because to write good programs you gotta understand the environment they're running in. Otherwise I'd be like trying to build a car but not knowing if you're building it for the city, Antarctica, or even the moon. The environment is critical to the assumptions you can make.

[0] https://en.wikipedia.org/wiki/Nice_(Unix)

[1] https://www-cs-faculty.stanford.edu/~knuth/taocp.html

They do, until you have a tough problem that's still too slow after it's cache efficient