Shaders are extremely fast, you should almost always use them if you want to animate the visual mesh frequently (e.g. every frame). Vertex shader has to be processes regardless, simple deformation code in addition often doesn't make much difference in vertex shader. Your CPU on the other hand will very quickly get overwhelmed if you need to process high resolution meshes frequently. The two main downsides of vertex shaders are that:
- they run every frame, you cannot run the shader once at the start and expect the deformation to stay in subsequent frames (while the CPU mesh modification will remain until changed again for no cost on subsequent frames)
- The vertex data from the vertex shader cannot be retrieved to the CPU side meaning you won't be able to use it to update the collision shape (if you use mesh collider) or otherwise use the data.
Water shaders for example use almost exclusively a GPU side solution for the waves but then need to resort to some extra measures to get the height data for floating things like boats. One solution is to calculate the required data points (wave heights for every floating device) separately on CPU side using the exact same math from the vertex shader
As a second example, the game terrain is generally done using actual mesh and if it needs to support terraforming, that is done in CPU script so that the collision shape matches the visual shape. That is often not an issue because the terraforming is often done very locally, on quite low resolution meshes, the terraforming doesn't happen all the time and the effect can be optimized by splitting the mesh into reasonably sized chunks. I'm not aware whether unitys terrain system supports such realtime modification, but that is just one example where you would generally use CPU side modification rather than GPU shaders.