My understanding of AAA game engine coding concurs with this analysis. It's become increasingly common to get more frames of graphics rendered in the same time span by kicking off the next frame before the first has finished, which can be extrapolated to a preconfigured buffer of many frames latency, similar to what is seen today with digital audio. Since game programmers already have to breathe concurrency problems just to achieve real-time stateful systems, and even more so to give an online multiplayer experience, this isn't a huge leap: many issues of this type have been resolved from the beginning with a double buffer or an intentional frame of latency.
That said, the benefits of scaling up runtime game performance are diminishing as asset costs increasingly dominate the discussion: the extra scene detail comes with a price to the production cycle, and that may be what breaks the games-graphics-tech alliance before any fundamental limits to the technology are reached.
See Halide, a latency-hiding scheduler/compiler for GPUs and CPUs...
Halide: a language for fast, portable computation on images and tensors http://halide-lang.org/
Programming languages often have some level of support for necessary primitives, such as goroutines, but then hide them behind an unsuitable scheduler. On the machines where latency-hiding was originally developed as an architecture (notably Tera's MTA), optimal scheduling was done by the hardware itself which had perfect visibility into relative latency with no overhead. Things are not that simple on x86/ARM. If you want to implement effective latency-hiding, you'll be implementing an equivalent scheduler in software, and often by inference because sometimes the only way to know the true latency of something is by doing it. I don't think it is that difficult but schedule design is not something most programmers know how to do well -- it is magic buried in operating systems and libraries. Nonetheless, you see more examples of this kind of software design for performance reasons.
There are very few real-world applications that are so serial that latency-hiding is not effective at using all available cores, particularly in the server realm where the workload is inherently concurrent. The original target application for latency-hiding architectures was scaling graph analytics, which are often not amenable to more classical embarrassing parallelism.