When rendering terrain, for efficiency you usually want to reduce the level of detail of geometry in areas far from the camera. As the camera moves around, you would adjust the level of detail to keep the area near the camera at high detail.
Geomipmapping, geometry clipmaps and suchlike are ways of managing this on the CPU. Although the GPU always does the actual rendering, you have to do a certain amount of CPU work each frame to decide which terrain chunks to draw at which LOD. You also have to take care of avoiding cracks when two adjacent chunks are drawn at different LODs. This tends to add a good deal of complexity to the algorithm, as well as using more memory and performance to deal with the extra crack-filling geometry.
The potential advantage of tessellation is that you would move this work onto the GPU. You could code a hull shader that would choose the appropriate level of detail for each patch and automatically generate the geometry for it. You would not need to store any terrain geometry, just the heightfield in the form of a texture to be sampled by the domain shader. On the CPU, you would simply render a single quad-patch (four vertices) for each terrain chunk—potentially including the whole terrain in one draw call. Because the tessellation hardware allows you to independently set tess factors for each edge of a patch as well as the interior, anti-cracking is easy to accomplish.
There's no reason why you would need to lose the 1-to-1 relationship between height samples and vertices. If each chunk is 64×64 height samples, and you draw it using a single patch with tessellation factor 64 (the maximum) then it will have one tessellated vertex per height sample. As the camera gets farther away you would reduce the tess factor, and then the resulting geometry will interpolate between height samples and/or not use all of them, but that's what would happen in any other LOD scheme as well. You could also increase tessellation beyond the number of height samples (e.g. a patch with 16×16 height samples, but tess factor 64). This could be useful for extra smoothing, e.g. if you implemented bicubic interpolation for the heightfield, or adding extra detail, such as from a detail map or noise function, or procedural destruction (as seen in some games where explosions will leave craters in the terrain).
As for whether tessellation is "exclusively" the way to go, that is difficult to answer. It's a tradeoff: it will reduce CPU overhead in managing and submitting terrain draw calls, but it will increase GPU usage, which you may or may not want to do. Also, tessellation is only available on DX11-class GPUs—which is all the new desktop/laptop GPUs being sold for the past several years, as well as the new consoles, but not mobile GPUs (yet) or the last-generation consoles. So it's wise to consider the minimum hardware requirements for your project before going all-in on tessellation.