This is not a bug of the cloth simulation. You are running into some special kind of numerical issue which gives you a false sense of works vs. works not. First lets state that the flag positioned at the world origin should not collapse.
Why should it not collapse?
You designed the flag to be perfectly flat, upright and oriented parallel to the XZ-plane a.k.a. the global Y-axis. Regarding the Y-axis, it has zero dimension. This is a physically idealised object which can't exist in the real world in this perfection. But the solver doesn't care. He happily applies gravity which points downwards (hence no forces spreading into the Y-axis direction) and all the cloth springs will only act within the XZ-plane. If the flag is stiff enough, it will support itself with some constant tension. Even if the stiffness is too low, the flag should bend only in the XZ-plane.
So why does it actually collapse?
Because it's not perfectly flat. There is a rotation applied on the flag to make it upright and this rotation, when evaluated causes numerical rounding errors to the vertices' coordinate values. A little caution has to be taken to see that in Blender: apply the rotation and then print the y-coordinate value of the vertices directly (printing the whole vector does not show enough digits, e.g. <Vector (-0.7143, 0.0000, -1.0000)>)
for v in bpy.data.objects["flag"].data.vertices:
print(v.co[1])
This gives:
4.371138828673793e-08
4.371138828673793e-08
-4.371138828673793e-08
-4.371138828673793e-08
-3.1222420204812806e-08
-1.8733452122887684e-08
-6.2444835968733514e-09
...
These values are very small but not zero. Looking at the "working" cloth simulation one can observe that at the beginning the flag supports itself and only after some frames starts to collapse. This is because the springs -due to the non-zero values- now have room to act into the Y-axis direction and at some point the numerical errors accumulated enough to make a difference.
Now the fun part: if we zero out the y-values explicitly again and run the simulation, it will behave like explained above and not collapse (even with all Stiffness and Damping options zeroed out, the flag will not make an inch into the Y-axis direction).
So why does it "stop working" if we move the plane away? Because the non-zero values are so small, that adding a small (but bigger) y-value cancels out the last digits so that the y-values converge to a constant value (if they are all treated as, say $1.0$, then we have basically the same situation as if they were all zero). In the following image, the flags have y-value locations of $0$, $0.01$, $0.02$, $0.05$ and $0.1$. Note how the flags take longer to collapse the farther away they are from the origin because the differences in the y-values are getting smaller and thus need more time to accumulate until collapse. $0.1$ is big enough to cancel out all other digits already, so we got a perfect flat flag again.
Note: moving the non-perfect flag along the X- or Z-axis makes no difference, its all about the zero-dimensioness in the Y-axis direction (you could observe the same if everything would have set up in the X-axis direction).
Therefore, the solution is to add noise to the springs, so they can act in all dimensions resembling a more real world like object. Moving one vertex a little is enough to trigger collapsing, but adding some average noise over the whole object seems more natural. One could use Mesh > Transform > Randomize with a visually not noticeable value for the job. Note that when you are far away from the world origin, the noise value also might have to be bigger for the same rounding error reasons. In the image there are the flags with $0$, $0.01$, $0.02$, $0.05$, $0.1$ again and another at $2$ from your inital setup. Randomize value is $0.001$ and the cloth simulation engine is your friend again :
Addendum:
The numerical rounding error behaviour is based on the fact that floating point numbers cannot represent any number but only a discrete subset (check out "Why 0.1 + 0.2 != 0.3 in most programming languages" if you are curious) and only have some consecutive digits for precision (for float it's around 7). Closer to zero, the representable numbers are denser, hence a better precision in calculations. This is the reason why one should be always not too far away from the origin when modeling/simulating and so on.
