This is a really poor article. Only in very rare circumstances can developers change the API's. API's are not "bad"; they are built to various important requirements. Only some of those requirements have to do with performance.

> “Well, it is fine to copy memory here and perform this expensive computation because it saves us one I/O operation, which is even more expensive”.

"I/O operation" in fact refers to the API call, not to the raw hardware operation. If the developer measured this and found it true, how can it be a misconception? It may be caused by a "bad" I/O API, but so what? The API is what it is.

API's provide one requirement which is stability: keeping applications working. That is king. You can't throw out API's every two years due to hardware advancements.

> “If we split this into multiple files it will be slow because it will generate random I/O patterns. We need to optimize this for sequential access and read from a single file”

Though solid state storage doesn't have track-to-track seek times, the sequential-access-fast rule of thumb has not become false.

Random access may have to wastefully read larger blocks of the data than are actually requested by the application. The unused data gets cached, but if it's not going to be accessed any time soon, it means that something else got wastefully bumped out of the cache. Sequential access is likely to make use of an entire block.

Secondly, there is that API again. The underlying operating system may provide a read-ahead mechanism which reduces its own overheads, benefiting the application which structures its data for sequential access, even if there is no inherent hardware-level benefit.

If there is any latency at all between the application and the hardware, and if you can guess what the application is going to read next, that's an opportunity to improve performance. You can correctly guess what the application will read if you guess that it is doing a sequential read, and the application makes that come true.