I think the other answers has already covered the bulk of this, yet I want to make some assertions on the P.S.:
P.S. So to stress my point: Why multiply the whole world by anything?
Because the world space does not match, it is representation on screen. For instance, in a 2D game, you may be contempt with applying an offset to the world position and drawing only what is in the bounds of the screen... not in 3D. Why? Because you have rotation and perspective. To archive these effects we use matrix transformations.
That is without solving the problem of occlusion. Without changing to camera coordinates you lack a way to tell what object hides another, and thus we need the transformation.
Furthermore, consider that you may need additional geometry (outside of viewing frustum) to make other effects, such as shadows or reflections.
I will only see the part of it! How this huge multiplication is avoided in game engines (openGL, ect).?
Game engines may resource to additional work to keep the GPU and CPU load low. It should be noted that video games has been using the techniques I describe below for a long time, and modern GPU hardware is much better than it was when they were first introduced.
Combining these techniques allows huge open world games with thousands or millions of objects, where sending everything to the GPU does have an impact on the performance.
For example, game engines no longer rely solely in the painter algorithm for 3D; instead, the engines leave the occlusion problem to the GPU, which can handle, for example, interlaced triangles thanks to the depth buffer. Although there are situation where the engine can optimize occlusion, it is not the general case.
Binary space partioning
Let's start at the age old Doom. The original Doom was big for the constraints of the hardware of the time. The engine was based on the one from Wolfenstein 3D which worked by ray-casting to find the distance to the walls across the horizontal field of view and scaling them in screen to make the effect of perspective.
Doom added vertical levels to the map, which meant that when a step on the floor was found, the engine had to revisit the area to find what is beyond that step in a recursive proccess... this implies that "complex" vertical structures (stairs) are very taxing to performance.
The solution was a technique known as BPS (Binary space partitioning), which in general terms means to divide the world in half (make a binary partition) and then in half again, and so... adding the whole structure to a tree structure that can be navigated to find nearby objects or objects that are in certain general direction from another. This means that they did not have to query the whole geometry each step.
Since, and thanks to Doom, BSP is common in game engines.
Split your world
We want to avoid loading the whole map at once. Instead, we want to load only the parts we need.
Various games for the original PlayStation would use every door of every room as a load point. It should be noted that loading was (and continues to be) a bottleneck for PlayStation.
But that doesn't means that there weren't clever solutions and workarounds. For instance Crash Bandicoot used narrow and sinuous paths for its levels, this allows hiding fact that only objects near the player are ever loaded, as the path twists often and keeps the distance the player may see limited.
Nintendo 64 had a different set of constraints. Even with better load speed, there is a cap for the size of the map. For instance, Mario 64 could not afford a large open world. Instead the world was divided in regions acceded by the pictures in the walls, and the size of each one was kept in check.
At some, point the same was considered for Zelda: Ocarina of Time (it would be constrained to Hyrule Castle, and you would enter pictures in the walls). Fortunately, improvements on the engine allowed for larger maps, yet there are still load points between regions.
Finally consider old GTA games, which divided the map in smaller ones. GTA Vice City had two main islands loaded separately, when the player is traveling from one to the other there is a load screen... from one city the other is visible at distance, but this is only a low polygon model.
Provessive load
Consider now Minecraft. In spite of its unsophisticated appearance, it has a high polygon count (consider all the triangles for all the cubes for a virtually endless map, that is a lot of vertex). How does it handle them? Well they are loaded in chunks, the engine only sends to the GPU chunks that are nearby the player.
If you experiment with render distance and other graphics options of Minecraft - or also due to a chunk that failed to load - you may find yourself looking at the void (well, just the skybox, actually) where there should be land.
Level of detail
GTA San Andreas did not have load screens dividing its map, how did they do it? They use LOD (Level of Detail)... GTA San Andreas works on a low polygon model of the complete game world (including roads and building) that is always loaded, and then other models are loaded on top of it (including roads and building, again). The models are replaced with other of higher level of detail as they get closer they get to the camera.
This means that if you move fast enough (or you PC is slow enough) you can catch up to the edge where models are being loaded... yet, thanks to the basic model that's always there, you will always see roads and a crude version of buildings instead of the void.
That much the state of the art (plus any custom optimizations for particular cases and any proprietary algorithms of which I am not aware). These technologies, in addition to the progress done GPU hardware allows huge maps such as those found in GTA, Skyrim, Red Dead Redemption, Breath of the wild, etc...
P.S. OpenGL? Not a game engine.
