There's an additional detail I want to clarify here:
As far as I understand (at least I would do this), we store the original mesh, and then for every change (shift, rotation or scaling) we turn the change into a matrix, and apply it to all vertices of the copy of the original mesh, with which we will work later.
This seems to imply that when I translate a mesh, the engine stops everything, moves every single vertex in the mesh, stores their new positions, then continues executing the next line of code. If I then rotate the mesh, it loads those stored positions after the previous translation, rotates every single vertex, then stores the translated+rotated results...
That's not how it works.
Instead, with each instance of a rendered mesh we store a "transformation" data structure, usually consisting of a translation vector, a rotation quaternion, an axis-aligned scale triplet, and a reference to a parent transformation (for hierarchical nesting of objects). We might also store a local-to-world or world-to-local matrix, or generate those on demand when needed.
When I rotate an object, the engine just updates the quaternion stored in its transformation data. When I translate it, the engine updates the translation vector. When I scale it, the engine updates the scale triplet. And that's it. Only those 3-4 numbers need to be recalculated immediately. We can then set a dirty flag to let us know the transformation has changed, and regenerate the matrix the next time it's needed.
When it comes time to render the objects, we run through our scene graph and update the transformation matrices of any objects that have changed (or whose parents have changed). Then we send that matrix and the raw, unchanged vertex data to the GPU to render.
Note that nowhere in this process so far have we actually moved a single vertex. Our mesh data often stays effectively read-only in memory. I can have thousands of differently-transformed instances of an object all referring to a single copy of the mesh data for that object, with every vertex exactly where I put it in the 3D modelling tool when authoring it.
The transformations get applied on demand in the GPU. The vertex shader gets passed each vertex in its original as-modelled position (what we call "object space"), and a matrix to use to transform that vertex into world space, or directly into the camera's projection space. So no matter how many transformations I've applied to the vertex, the shader only needs to do a couple of matrix multiplications to find its final displayed position (and possibly transform its normal, tangent, etc). All those sequences of translations and rotations get folded down into a single matrix, so computing the result of 1000 transformations is no more expensive than 1 for each vertex.
That transformed vertex position gets sent down the pipeline to be rasterized into pixel positions to draw, then it's effectively forgotten at the end of the draw call. We don't store the transformed vertices anywhere, we just re-transform them again cheaply next frame.
Now, I've glossed over here a few special cases where we will compute new vertex positions CPU-side, like when we're dynamically batching multiple meshes together into one common coordinate space to draw in a single call. But those are exceptions to the rule.