Not really, that's more related to the fixed precision of IEEE 754 floating-point numbers. In any fixed-precision representation there's always a certain representation which happens to be the best approximation of any constant like pi. That's the one you would pick.
However, you could perhaps infer from the article that IEEE 754 double-precision numbers are sufficient for most physical calculations.
Other way around, they use that value because that's the most precision you get with IEEE-754 64-bit floating-point numbers, which is the representation also used by JS for floating-point.
The value was superior to mathematical Pi (as is best float approximation, but not best double approximation), such as having 2*PI normalized into [0,2*Pi] by standard trigonometric functions (which use accurate approximations of Pi) would not preserve it and yield a value close to 4.2e-10, which could cause suprises (for example if angular ranges are defined as (start,end) and not (start,span)).
I'm surprised you'd have to define pi in a fragment shader at all. Surely such a commonly used constant would be defined in the language/headers already?
I've always though about that fact myself. Can somone find the answer to why didn't the GLSL designers / video card driver people make PI built into their language?