ball.y += ball.vy;
ball.vy += gravity;
Taking a look at the collision detection, look at this line of code:
ball.y = platform.y - ball.radius;
Lastly, in this particular line of code:
ball.vy *= -0.4;
Conclusion? Collisions are hard !
The integrator uses a lot of math. It gives the positions of everything at time t and time t+D, where D is the timestep. The integrator functions under the assumption that no collisions occur.
The collision detection/response system takes as input the integrator's output, namely the positions of everything at time t, and at time t+D. It finds the earliest collision, say at time t+d where d < D, and does something about it -- usually changing position and velocity of the objects involved -- and then re-runs the integrator from time t+d to t+D, again stopping to process the earliest collision.
The important point is that your results are "good enough" if the collision detection just assumes objects travel in a straight line at constant velocity between their positions at t and t+D. The exact path is something that's confined to the integrator, and only linear paths exist in the simulation outside of it.
Of course there are various optimizations and corner cases you have to take care of -- like making sure colliding objects don't immediately register a second collision when the integrator is restarted, and bounding the number of collisions an object is allowed to experience per frame (to handle for example a ball resting in a V-shaped cup from alternating collisions between the two pieces of the cup thousands of times per frame).
And you can optimize since you don't actually have to re-run the integrator for objects that didn't change their physics state (position/velocity) due to the collision.
I remember I wrote a fun little OpenGL game  some time ago, with flocking agents aka boids. I had a lot of fun making the creatures' "thinking speed" independent of the rendering speed and the simulation speed of the virtual world itself.
[review paper discussing lots of techniques]
[A PhD thesis with good background material]
While this is true, consider that the huge library of built-up optimizations in a well used collision library like Havok very likely makes up for these checks.
Alternatively, they generally offer a lower level API such that you could just always call: `Havok::CheckCircleAAPlane` and then not have to worry about Havok doing it's dispatch. But then again if you don't use Havok's spatial culling you're likely missing out on a whole lot of optimizations, and advantages to using Havok.