Don’t bother to recreate from scratch the whole scene, you’ll get again the same problem since it’s caused by the physics engine itself, as Rob pointed out.
You can check it by yourself, adding these lines in the ball script, and disabling temporarily the OnCollision method:
void FixedUpdate(){
Debug.Log("Ball velocity: " + ballRigid.velocity.magnitude);
}
This will show in the console the magnitude of the velocity vector, and you’ll see that the value will remain always the same (of course), around 20.1 in your case ( sqrt(20^2+2^2) ), even when the ball will start to have a really low y velocity component.
And if you notice, the y component of the velocity retains the same absolute starting value, and it just changes its sign every collision, until the ball hits a brick or the paddle at its corner: at this moment, the physics engine will “transfer” a huge part of the y velocity component to the x component, whereas the magnitude will remain the same.
And the more it happens (hitting corners), the more the x component increases and the y component decreases, up to the point that even adding a random number will have an almost negligible effect.
The solution? Scrap away box colliders from everything, and use polygon colliders with rounded edges, something like this for the paddle, for example:
For the bricks clearly you need to smooth both the upper and lower corners, and I strongly advice to smooth even the cornerns of the side colliders, this way you’ll avoid the y velocity component bug AND will give more control to the player (the more the ball hits the paddle near its edges, the more y component will be transferred to the x component or viceversa, depending on which side of the paddle is hit by the ball).
And you’ll be able to remove that random modifier of the ball velocity, which is really ugly. 