I'll try to address your specific questions.
Is this the best way of drawing a sprite? Is it suitable?
It's suitable, and it works, but it's not the best way to do it.
What gl* calls really do
What you are doing is sending commands to your video card. Just about any function you call that begins with 'gl' does so . Thraka did a fairly good job of explaining some of the commands you're using already.
The glTexCoord2f() and glVertex3f() function calls you are making interact with your video card drivers, which then send commands to the video card, which does all the real work.
The reason this isn't the best way to do it is because you are making a single function call and sending your data to the video card, for every vertex, every time you draw this quad. Imagine if you could send the data to the video card once, and then tell the video card to draw "that thing" you sent earlier, instead of telling it each time you draw what the coordinates are. This is referred to as a Vertex Buffer Object, or VBO.
Can anyone help / Does anyone know any tutorials on this weird coordinate thing?
Now it looks like you're just getting started, so I wouldn't worry too much about anything I just said. I especially wouldn't worry about using the most efficient way of rendering things. Hopefully it gives you an idea of what you're really doing, though, when you make these function calls.
To really understand the relationship between the X and Y coordinates you worked with in Allegro and the 3 dimensional coordinates (and the immense flexibility therein that OpenGL gives you), you really need a good math background.
I believe it was pre-calculus where I learned about rotations, scale, and translation, and how a 3x3 matrix could be used to represent all these things in a two-dimensional space. If I had paid more attention then, I might be a better game developer today, but that's beside the point. This is the kind of thing that's fundamental to understanding how to work with OpenGL. Of course, OpenGL is a 3-dimensional API, so things therefor get a little more complicated, but the same way of thinking extends well. However, you can get by without understanding the intricate details of transformation matrices as long as you understand some basic concepts.
Think back to some geometry (or similar) studies you've done. You usually describe the position, shape, size, and so on of an object relative to the origin ( (0, 0) in a two dimensional space). If you say a point is at (2, 2) you are saying it is up two and right two from the origin.
What is this origin? A better question is where is it? It's completely arbitrary. You can't tell someone your house is at (x, y) and expect them to know how to get there. You could possibly give them the latitude and longitude of your house, but these are coordinates in a similarly arbitrary coordinate system. Latitude and Longitude only have any meaning because everyone agrees where the Prime Meridian and the Equator are.
Similarly, there are directions involved. In a 3D world, there is an up, a right, and a forward. This is incredibly intuitive to you because your right hand has always been your right hand, up has always been up, and forward has always been in front of you. But in an arbitrary coordinate space like we are talking about, these things have to be specified before anything makes any sense.
When you work with OpenGL, you need to think in similar terms. If you tell OpenGL to draw something at (0, 0) you're telling it to draw at the origin of the current coordinate space. This coordinate space defines where the origin is, these principal directions, and some other things like scale that may be important.
I'll try to give an example of how this could all be practically used.
Imagine you have taken your room and modeled it all in something like Google Sketchup (or any other 3D modelling program.) You've got windows, your bed, and your computer in there. Where is the origin? What is right, up, and forward? Lets say you just started modeling everything without thinking about any of this, and these things happen to correspond to the doorway to your room. That is, in your virtual world, you are at the origin and looking forward when you are standing in the doorway facing your room.
Now you've saved this whole virtual world (your room) to a file. And you've decided to model the rest of your house. You start a new virtual world (your house) and put the other rooms in there, the backyard, kitchen, etc. Now lets say you've modeled everything in your house except your room. First, lets consider where the origin of this virtual world is. We'll say you decided to call it, again, the doorway to your house. The origin is the doorway to your house, forward is the direction you are facing when you look into the house, etc.
All the items in your room are saved currently relative to the doorway to your room. But you want to pull your room that you previously modeled into your house. What needs to happen (and what the modelling program will do for you automatically) is that you define the position and rotation of your room relative to the coordinate space of your house.
Assume, now, that we have "your room" positioned in your house relative to the front door. How do you determine where, in your house, the computer is in your room? You have to transform the computer's coordinates from your rooms' coordinate system to the coordinate system of the house. Since you've defined the orientation of your room relative to your house, you can now do this.
How this relates
Imagine the computer monitor you are currently looking at is a camera, or an eye, looking into a virtual world. If you play a first-person-shooter for a bit, this isn't hard to do. The monitor, of course, isn't actually moving; it's only depicting a changing perspective into a virtual world.
From this point of view, how might you make the impression of a two dimensional space, like many games (such as Mario)? Imagine (again) that you take a board game, like Monopoly, and want to film it. The board game is essentially 2-dimensional, but the camera you are using captures an entire 3-dimensional world. If you place the board of Monopoly on a flat table, and then position your camera a couple feet above the board, facing directly downward towards it, you'd end up capturing the Monopoly world in its 2-dimensional glory.
This is exactly(1) what Allegro does for you. You give it two dimensional coordinates and it translates them into 3-dimensional coordinates that work out exactly the way you want.
One convenient way of doing all of this is by using a matrix. As I said earlier, orientations in a 2-dimensional space can be described by a 3x3 matrix. Similarly, orientations in a 3-dimensional space can be described by a 4x4 matrix. The real convenient thing here is that to "jump" from one coordinate system to another, you just have to multiply the existing matrix by another.
If you describe the location of the computer in your room as a 3-dimensional vector, you can multiply this vector by the room's transformation matrix to find its position in the house-space. The matrix math would look something like this:
[ n, n, n, n, [ x,
n, n, n, n, * y,
n, n, n, n, z ]
n, n, n, n ]
I don't want to bog you down with the specific numbers in the matrix and their meaning, but this should give you an idea of the relationship. The 4x4 matrix on the left is our theoretical transformation matrix that describes your room's orientation, and the vector on the right (or 1x3 matrix, if you will) describes the position of your computer relative to your room.
Back to our house example, lets imagine a third coordinate space. Lets say this is the city, and that the origin is at the city hall, and that this coordinate space is facing north. Now we have 3 coordinate spaces, described by 3 matrices:
M1 - city
M2 - house
M3 - room
And we have one particular object, your computer, with a vector describing it's location relative to the room:
We can do some pretty cool stuff now:
The position of your computer relative to the house is:
M3 * V1
The position of your computer relative to the city is:
M2 * M3 * V1
And if we say the city's coordinate space is relative to "world space," we can say that the position of your computer relative to "world space" is:
M1 * M2 * M3 * V1
I'm tired of writing, and unfortunately there's still a bit more in your question that may not have been answered (specifically about texture coordinates.) Hopefully my voluminous answer has helped you understand the code you're writing though, and helped you understand some of the concepts needed to work with OpenGL.
(1) Allegro may not do exactly this, but this should give you the idea of the relationship between 2D and 3D in OpenGL.