From my experience, denormalization of a relational model is a special case of "caching". What you are really doing is caching data where it is most likely to be used at access time.

The overview is like this:

1) You need some operation to have low turnaround time / latency

2) So you maintain and update a cache, typically while writing to the data store.

3) Like all caches, you can either invalidate it before changing the data, slightly harming availability, or you can have it lag behind (eventual consistency).

So the article is actually wrong, you don't need to trade consistency for performance. You can increase read performance (lower latency) without losing consistency, by having a cache (denormalization) and invalidating the relevant caches BEFORE writing data (which lowers write latency, but not necessarily write throughput... typically, we don't care about write latency as much as read latency.)