Red is the "corner pixel" of the balls rectangle before, orange is the same pixel after. It should be obvious that during that movement, this pixel would intersect the corner of the box. No matter how many "snapshots" or "sub steps" you make, no matter how small your movement, you can _always_ miss collision if you only check for static intersections. The term "corner case" very much applies.
The simple point is this: collisions are dynamic and involve motion. If your collision detection ignores the objects motion, you're not doing collision detection. Sometimes you won't care, but usually you should.
Since break out is using neatly axis aligned boxes and is in 2D, I would highly recommend using this as a chance to learn how to "do it right", rather than waiting with it until you need to do arbitrary geometry in 3D, where some basic concepts might be the same, but their implementation will become a lot more complicated by having to handle the "generic case". "Right" in this case can either mean diving into the lovely world of collision physics (at least a simple sub set, to get the hang of it) or picking a good physics engine and just not worry about the mathy details.
The typical approach is to determine the time of (potential) intersection (t) for each potential edge, then sort by t and determine if they do in fact intersect.
This is were it becomes important to not randomly talk about "lines" when you mean "line segment". Lines are of infinite length and you typically check against a block edge's "line" first, then see if the intersection with that line is actually on the "line segment" (this is why you might want to consider treating the ball as a point, rather than a sphere, as it's making things a "lot" simpler, especially where hitting corners is involved).
To determine if the ball has any chance of hitting one edge, if it was on one side before and on the other after, you need to see if the point of intersection is on the actual edge of the box. If it was intersecting before, you probably have a bug (or are discovering why floats should never be compared with ==), if it is intersection after, treat it like being on the other side.
There are lots of things that make it easier. For example, knowing the balls velocity has positive x, you never need to check against a blocks right side. Knowing the box is convex, you never need to worry about hitting an edge at a right angle (as it is then covered by another edge), etc.