Math.random() is not intended be a _good_ source of random -- it's essentially expected to be on par with C's rand(), although IIRC most implementations are better.
There are APIs for cryptographically secure random numbers, but Math.random() is not it.
There's a difference between cryptographic security and quality. Cryptographically secure generators typically have (empirically verified) high quality from a statistical perspective, but they're not a general solution for all purposes. They're relatively slow, you can't seed them, and they don't typically have rigorous mathematical proofs of certain characteristics like equidistribution and cycle length.
The article doesn't suggest Math.random() should be cryptographically secure (although that is an option). Rather, it's a critique of the algorithm that's being used. There are better algorithms with no drawbacks that produce sequences you can safely assume have a statistically random distribution (even if the sequence is predictable and is therefore not cryptographically secure).
True, but there's also no requirement for quality -- the webkit/javascriptcore rng is a trivially simple generator, with no real statistical analysis performed -- back in the day i ddi some rudimentary testing (simple things like the birthday and pi tests) -- the only real reason you could get away with it in this use case would be that it use a separate ring for every page, and those rngs are seeded from "true" random on every load.
"Xorshift generators (also discovered by Marsaglia) are fast and do very well on statistical tests (much better than MWC1616). An xorshift variant called xorgens4096 has been implemented in Javascript by David Bau. It has a 4096-bit state space, a cycle length of ~2⁴⁰⁹⁶, and it runs faster than MWC1616 in Chrome on my machine."
there is no reason not to have a better math.random().
There are APIs for cryptographically secure random numbers, but Math.random() is not it.