Lots of things get weird in edge cases with SVGs. E.g., one thing that keeps biting me is that Firefox always snaps x="X" y="Y" coordinates on <use> elements to the nearest CSS pixel (even if the pixel size is very large), but allows transform="translate(X,Y)" to keep its full subpixel precision. I've taken to double-checking all my SVGs at 3000% zoom just to spot all the seams that implementations can create.
As in n+1 == n once you go past 2^24 on a float and here they are at 2^25-1. So it doesn't quite make sense as a reason to me.
There's a post above that browsers divide pixels into 1/64th of a unit which accounts for 6bits which puts this limit at precisely that of a signed 32bit integer. This makes much much more sense than the significand of a float.
The correct answer. In particular, up to 2 ^ 24 the float32 behaves like a regular integer, which can be important in some cases. Above that value, the integer starts to have missing values, and strange int behavior such as (n+1)+1 not equal to (n+2)
But why are 32b floats relevant? JS, the language famously representing ints as floats, uses 64b floats. Who puts ints into 32b floats and cares about precision loss?
I didn't say JavaScript anywhere in my comment. No relation to JavaScript. Rendering is typically done in tiles, in GPU, and the best precision that can be used across all GPUs is float32. Some GPUs don't implement float64.
Now SVG… try defining a view box up where float precision drops, and interesting things happen.