[jstimpfle]

IME, separating I/O in the code works because it literally is separate -- it usually happens at the boundaries of the application. It rarely makes any sense to connect two code components (running in the same process) with a disk-backed information path. And where it does make sense -- well, your I/O code moves deeper inside the application.

The "boundary" argument works even better where it's about network I/O or video output, because applications are even less likely to connect code modules using such types of data.

Other than that I don't buy much into that I/O vs "pure" at all, it's pretty much an arbitrary categorization since there really isn't much of a difference between writing to disk or memory. I think the idea that writing to memory is somehow purer comes mostly from Haskell and similar languages that somewhat enforce immutability at the language level. Given that it is still an artificial categorization I don't take this too seriously. The one benefit I see is that it often does improve clarity of architecture to have mostly construct-consume-discard data access patterns without any mutability after construction. Oh, and potentially you can handle errors from disk I/O, while you cannot really handle errors from memory I/O.