I work more on the enterprise side of things, doing information analysis harrumphitywhatnot. My data tends to look a lot like the example in those slides, my performance drags look a lot like what those slides warned about, and a lot of the tricks I've come up with for keeping performance up look a lot like what was shown in the slides.
Far from concluding that this doesn't apply to me because I don't work in C++ and I'm not a game developer, I think I need to take some more time to read the game development literature to see what else I can learn.
It applies to any operations over sets of data. Do you search or sort numeric or text data? Then this applies. You want to structure sets of things in contiguous blocks of memory to the extent possible.
I've really enjoyed reading http://bitsquid.blogspot.com/ . It runs right from the birth of their game engine right up to the recent acquisition by Autodesk. They are heavy proponents of data-centric design with flat layouts (no pointer graphs jumping all over memory). The result is a game engine where almost anything (from rendering pipelines to physics models to ai) can be changed, compiled and live-updated on a nearby console in under a second.
We might also think of this as modern architectures being very badly suited for supporting these mechanisms for abstraction. This may indicate an opportunity.
This is about game programming, and how to optimize your data to be cache- and prefetch-friendly.
If your data doesn't look like game data, or isn't accessed like game data, it won't help and the "pitfalls" aren't.