In short - it is better to do the transformation on the GPU.
Firstly, the GPU is designed to support huge amounts of parallelisation. Your CPU on the other hand is not nearly as capable. The NVIDIA GTX 980, for example, has 2048 CUDA cores to process those vertices with in comparison to the 2-16 threads/cores a processor might support.
So from a number crunching point of view alone, the GPU is going to be better.
However, there is a far more obvious reason to do this on the GPU. While passing data data across the bus to the GPU might be expensive, it's not so expensive that passing a world, view (worldview) and projection matrix for every mesh is going to be a concern. However, passing all meshes every frame will be, and that's what you need to do if you process the vertices CPU-side.
In the normal pipeline you generate a vertex/index buffer, pass it to the GPU and render. At this point the GPU has stored the data in it's own internal memory. You then only update when something in that mesh changes. Usually this is only for dynamic buffers, such as might be used for a particle or sprite batching system. Most objects should be in static buffers which are only passed once - when the object is loaded for the first time.
If you are then manipulating that mesh each frame to change it's position then you are saving on passing the matrix by working CPU-side but now have to re-send all of the vertex data instead.
If your object is static and so will always use the same transform matrix you still get no saving by doing the transform CPU-side as you still probably have a moving camera. You will, in a normal render pipeline, eventually need the vertices in camera space so you need to perform this transformation as well and quite often people combine the world matrix with the view matrix so there's a single object to camera space transform matrix - often called the worldview matrix.
Note on Geometry Batches
One of the only occasions I can think of where you would want to perform this transformation CPU-side is when batching multiple meshes into a single buffer as might be done for static geometry (that shares materials), particles or sprites.
In this situation what you would really be doing, however, is translating the vertices into a common space for the buffer. Having one local reference space for each buffer means no extra vertex data is required to determine how to later translate that vertex to screen-space.
In other words, if you batched two buildings into a single buffer but didn't translate the vertex positions to a common space you would have to pass two world matrices and flag each vertex to determine which to use on each vertex. This can actually be achieved by using two separate index buffers (one for each building) and rendering in two draw calls with different world matrices but with the same vertex buffer in place.
Usually the common space is simply world-space, but could equally be camera space or some other local space if that was convenient for some reason.
Even in this case, however, you probably do this as little as possible and perform the translation to camera-space, then screen-space, using the GPU each frame.