This paper isn't about a faster RNG, and it's mostly only of interest in a computer science context rather than in an applied cryptographic context. These results reduce the theoretical requirements needed from two weak sources of randomness in order to combine them into a source of true randomness. However, in the applied world, we already have "enough" — a few bytes can seed a CSPRNG that will generate effectively infinite computationally-random bytes.
When systems today fall over due to randomness issues, it's usually due to systems-engineering failures: a good RNG wasn't used (despite them being widely and easily available), or not enough initial randomness was seeded (e.g.,
/dev/urandom on an embedded device), or a virtual machine was copied and restarted with the same initial random seed. These classes of problems aren't solved by improving our sources of randomness.
To your question directly, a faster RNG isn't of much practical use. A stream cipher seeded with enough randomness is effectively a DRBG, and can produce random bits extremely quickly — far more quickly than is needed for the overwhelming majority of use-cases. The operations that use that randomness typically execute far more instructions than do the operations to generate it.
Thomas Ptacek's response to this story on Hacker News is how I expect most crypto people feel about this.