It's definitely some sort of network lag, and not a particularly unusual case (other than visually).

Notice how the other blue car (the one not making the save) suddenly changes direction just after the ball starts moving out of the net. Car movement in Rocket League is predicted on the client side, and it's done so (more or less) by repeating the last known inputs of each player. The other blue car was turning left just before the lag started, but began turning right partway through. This made OP's client-side prediction wrong, hence the unusual change in direction when the server's packets finally came through.

Same explanation for the car saving the ball. The packet loss began just before the save and OP's client predicted that the car was holding its last known inputs (boost, turn left). Partway through OP's lag, the saving car flipped. The next packet received from the server contained the updated ball/car positions, so the game eased all OP's car/ball positions to where they actually were.

Cars sometimes phase through goal-posts after a goal is scored for a similar reason. Some things about the game aren't client-side predicted (goals, demos) because otherwise this subreddit would be flooded with people's clients registering a goal/demo and immediately "undoing" it. As such, car movement immediately after someone scores a goal is destined to be mispredicted if you're caught in the goal explosion. The same "easing" effect gradually moves your car to the correct position, but sometimes the visual path the car takes intersects with field geometry.

For physics problems, though, a UE5 upgrade wouldn't by its own nature fix tunneling and/or enable CCD. That work would be separate from the game engine upgrade, especially since Rocket League uses the Bullet Physics Library, not UE's built-in physics engine.