The most correct answer is, it depends on how you program it, but this is a good thing to worry about. While GPU's have become incredibly fast, bandwidth to and from GPU RAM is not, and will be your most frustrating bottleneck.
Does its data get sent to GPU memory only once and sit there forever?
Hopefully, yes. For rendering speed, you want as much data to sit on the GPU as you can, instead of re-sending it every frame. VBO's serve this exact purpose. There are both static and dynamic VBO's, the former being best for static models, and the latter being best for models whose vertices will change every frame (say, a particle system). Even when it comes to dynamic VBO's, though, you don't want to resend all the vertices every frame; just the ones that are changing.
In the case of your building, the vertex data would just sit there, and the only thing that changes are your matrices (model/world, projection, and view).
In the case of a particle system, I made a dynamic VBO big enough to store the maximum number of particles that will ever exist for that system. Each frame I send the data for the particles emitted that frame, along with a couple uniforms, and that's all. When I draw, I can specify a start and end point in that VBO, so I don't have to delete particle data. I can just say don't draw those.
When the model gets actually rendered each frame do GPU processors have to fetch its data each time from GPU memory? What I mean is - if I had 2 models rendered multiple times each - would it matter if I first rendered the first one multiple times and then the second one multiple times or if I rendered the first one just once, the second one just once and kept interleaving it like that?
The act of sending multiple draw calls instead of just one is a much bigger limit. Check out instanced rendering; it might help you out a lot and make the answer to this question useless. I had some driver issues with it that I haven't worked out yet, but if you can get it working, then problem solved.
Obviously graphics cards have limited RAM - when it can't hold all the model data necessary for rendering 1 frame I guess it keeps fetching (some of) it from CPU RAM each frame, is that correct?
You don't want to run out of GPU RAM. If you do, then change things so you don't. In the very hypothetical scenario that you do run out, it'll probably crash somehow, but I've never seen it happen so I honestly don't know.
I forgot to make one distinction: there's sending the data to the GPU and there's setting/binding the buffers as current. Does the latter cause any data flow?
Not any significant data flow, no. There is some cost to it, but that's true for every line of code you write. Finding out just how much it's costing you is, again, what profiling is for.
buffer creation with initialisation
Raxvan's answer sounds good, but it's not quite accurate. In OpenGL, creating the buffer does not reserve any space. If you want to reserve space without passing any data, you can call glBufferData and just pass null. (See the notes section here.)
buffer data update
I'm guessing you mean glBufferData, or other functions like that, right? This is where the real data transfer occurs. (Unless you pass null, like I just said in the last paragraph.)
binding the buffer as active (is it just a way to tell the API that I want this buffer to be rendered in the next draw call and it doesn't do anything by itself?)
Yes, but it can do a little more than that. For example, if you bind a VAO (vertex array object), then bind a VBO, that VBO becomes bound to the VAO. Later, if you bind that VAO again, and call glDrawArrays, it will know what VBO to draw.
Note that while many tutorials will have you create a VAO for every VBO, I've been told this is not their intended use. Supposedly you should create one VAO and use that with every VBO that has the same attributes. I haven't tried this yet, so I can't say for sure whether it's any better or worse.
API draw call
What happens here is pretty straightforward (from our perspective). Say you bind a VAO, then call glDrawArrays. You specify a starting point, and a count, and it runs your vertex shader for every vertex in that range, which in turn passes its outputs down the line. That whole process is another essay of its own, though.