The author of that piece hasn't thought hard enough about the issues. floating point, no matter if it is binary, decimal, base-100, or oct-precision will always cases where numbers are not exactly precise. That is an inherent issue with floating point that must be considered, and the author makes a mistake to attributing his problems to floor() and ceil() instead of floating point.

0.005 works for his domain, and someone else may find that 0.001 is what is right for them, and the existing floor() and ceil() functions give them predictable tools to do that. If he only needs to draw boxes on integer aligned grids, that solution is fine, but it will break all over again if he tries drawing rotated boxes, lines, triangles, etc (plus he'll find other numerical issues that he can currently ignore).

He says 0.005 is an acceptable fuzziness. But now 17.9949999 will round down and 17.9950000 will round up. That cliff is still there; he has just moved it and thinks he solved it. A guy I used to work with called this "squeezing a balloon" -- you didn't fix the bulge, you just moved it somewhere else.

Finally, he appears to approve that printf prints 18.0 when the input was 17.999999. That is convenient in some cases, but a lie in others:

a = 17.999999 b = 18.0 print a, b --> 18.0, 18.0 print a - b --> 0.0000001