Note that this is "broken" in a very tiny way, which is unlikely to cause any real-world problems in code which uses floating-point correctly, i.e. does not rely on its exactness (or lack thereof.) It's not like with integers, where e.g. 1000000 becoming 999999 or 1000001 would be a severe bug.
If you're interested in the details of floating-point maths, the rest of the site has other fascinating articles too. Converting strings to and from floating-point correctly in all cases turns out to be quite a tricky thing to do in practice.
It's perfectly fine as long as you know the rules. Virtually all JavaScript code is heavily reliant on exact answers from floating point (since floating point is all you have) and it continues to work. :)
They are heavily reliant on exact answers for the subset of small integers. But not that edges cases are handled 100% correct. Denormals, trigs of very large number, parsing of numbers with lots of significant figures.
It could lead to degraded precision for mathematical calculations with lots of steps, but that should be a problem for only a small minority of js code.
Sure there's a trade-off (you need multi-precision calculation) so it's fine to sacrifice precision over speed/footprint as long as that's the explicit design choice. If it's not an explicit choice, it's a bit disappointing.
If you're interested in the details of floating-point maths, the rest of the site has other fascinating articles too. Converting strings to and from floating-point correctly in all cases turns out to be quite a tricky thing to do in practice.