Only, that it doesn't give you any extra memory at all. In case you're using a dedicated GPU, the peripheral bus inbetween (PCIe) is a serious bottleneck. In addition to that the OpenGL object model does not have the concept of automatic "object eviction"; on embedded architectures (Android) you may loose the OpenGL context and have to recreate it. But you'll never loose a single OpenGL object.
The bottom line is, that the OpenGL driver will create a backing store in system memory for each and every buffer object. So if you allocate 4GiB of OpenGL buffer objects, it will allocate 4GiB of system memory; if it's a shared memory GPU that's it, if it's a dedicated GPU the GPU RAM is actually more of a cache to the backingstore.
glMapBuffer will usually just give you access to this backingstore so that writes can be coalesced into a single transfer when unmapping. Also you don't want a full round trip read-modify-write. In case of coherent mappings the coalesced transfer is triggered by a GPU side data read operation on that buffer.
TL;DR: RAM on graphics cards is a cache on top of system memory (as far as OpenGL is concerned).
The bottom line is, that the OpenGL driver will create a backing store in system memory for each and every buffer object. So if you allocate 4GiB of OpenGL buffer objects, it will allocate 4GiB of system memory; if it's a shared memory GPU that's it, if it's a dedicated GPU the GPU RAM is actually more of a cache to the backingstore.
glMapBuffer will usually just give you access to this backingstore so that writes can be coalesced into a single transfer when unmapping. Also you don't want a full round trip read-modify-write. In case of coherent mappings the coalesced transfer is triggered by a GPU side data read operation on that buffer.
TL;DR: RAM on graphics cards is a cache on top of system memory (as far as OpenGL is concerned).