Why would you expect anything else if you clear the buffer, draw only the paddle and then display only the paddle?

How does this even compile if 'i' isn't declared in paddle_left (and if it's global... can you tell why naming a global variable "i" is just incredibly bad and confusing?)

And how is this ever going to work if the next time you draw your scene you will always draw the paddle in exactly the same position, no matter what?

How will you ever "remove" a brick if drawing them is hard coded like that?

Why is that loop copy pasted for every row of bricks and how will you ever be able to have any other number of rows in a level?

You need to take a very big step back and realize that the stuff drawn on the screen isn't the "game", but takes the current state of the game and visualizes it. AI players (or psychics) should be able to play without needing ANY kind of graphics of drawing. In one nice Google friendly acronym: "MVC".

A buffer in OpenGL isn't a stage where you put stuff and then move it around, it's a ton of pixels that need to be rendered again for every frame (unless you really know what you're doing and invest a lot of head ache to optimize something that absolutely doesn't need to be optimized).

I assume you call paddle_left whenever the paddle is supposed to move left? That's why your bricks disappear. As soon as paddle_left is called, the buffer is cleared and only the paddle is drawn. Anything else that was drawn (perhaps during a previous call to draw_scene) is wiped when glClear is called inside paddle_left.

What you are doing here is just... no. There should be one place, and one place only where things are drawn. The proper place is not inside whatever logic you use to make paddles move. You might want to take a break and do some research on basic game loops: how they're structured, what pieces go where, etc... Mixing logic and rendering like you are doing here is just not going to cut it.

Typically, a loop proceeds through a set of tasks in a pre-defined order:

1) Call Time() to get the start of frame time

2) Process any waiting input events, and hand the results off to interested parties. Here you might call functionality to move your paddle, for instance by adding or subtracting a value from its position. Only that, though; no drawing, no buffer clearing. Just input handling.

3) Update logic. How this is done varies; some setups will update logic on a fixed time step (every, say, 1/60th of a second) while others will compare the current Time() against the Time() of the last logic update, and use the difference as a step length. In this stage, only logic is performed: things are moved, decisions are made. No drawing. None whatsoever. Doesn't belong here, either.

4) Update collisions. This process might be interleaved with your physics step, depending on how you are doing your physics. At any rate, here you account for the things that happen when a collision occurs. Break blocks, bounce balls, check for ball out of bounds and decrement ball counter, and so on. Again, no rendering. These stages of the loop don't care what goes on the screen. As Trienco indicated, they should do what they do even if nothing is ever drawn on the screen. Any drawing code in these sections should actually generate compile errors, because there is absolutely no reason these modules should even know what OpenGL is. That's how you avoid problems.

5) Render. Aha! Here we go, now that everything has moved to its new location, we can draw the screen. This part of the loop doesn't care about logic or physics or things moving or input being handled. If you are doing any of that here, you are doing the wrong thing. The only thing this part of the loop cares about is drawing the stuff it's told to draw on the screen. There should be exactly one call to glClear() and one call (after drawing is done) to swap buffers. Any more and you are just going to eradicate work already done. Clear the buffer, draw your game, draw your UI, swap buffers.

6) Repeat.

There are many variations to the loop, but that is the basic gist of it. You might want to read the usual suspects when it comes to game loops (Gaffer's fixed time step article, the Bullet physics canonical game loop, etc...) in order to really understand the processes and how the different sections need to be separated. Make any number of throwaway applications as you need to get this figured out. Without this basic understanding, you are just doomed to repeat your past failures and cause yourself more frustration.