tldr; Wysilab is absolutely correct on their approach.
First, regarding your last comment, in my honest opinion, I think it's the other way around. You define the look of what you're creating, and when you're happy with it, export it to whatever resolution you want to use.
Now regarding the mesh density and size, I think this is just a bit of misunderstanding on why things are like this.
First, about the size. As Alexis said in his own words, vertices are mapped to pixels, one by one, so you can correctly reconstruct the mesh when reading the texture. If you have 1025x1025 vertex positions, you need 1025x1025 pixels.
Now why is it 1025 and not 1024?
A single quad mesh has 2x2 vertices. One for each corner of the quad. If you slice it up in the middle, you have a 2x2 quad with 3x3 vertices, because they share the edges, so they share the vertices. If you slice each quad in the middle again, you'll have 4x4 quads with 5x5 vertices. You need that +1 pixel. You shouldn't just "guess" the last vertex height just to keep the texture as a power of two. That doesn't make sense.
(ignore the quad colors)
The 3D software/engine reads the texture and reconstructs the terrain mesh. That's usually not a realtime thing, so it's not a problem that its size is not a power of two. The engine will convert that information to their own data structure.
Supposing you used a 1024x1024 texture to recreate a 1024x1024 terrain, you would end up with two of the terarin edges (probably the right and top ones) copying the previous pixel information. If you're using just one terrain, it might work just fine, but if you're tiling and stitching terrains together, that means that at each terrain intersection, there will be a mismatch between one terrain and the other.
There would be a different case if you were loading the texture at runtime to raymarch the terrain texture and recreate that terrain per pixel. In that case, I'd just crop out the extra pixel (you can automate that with instant terra api).
Now about size, @Alexis feel free to jump in and correct me if I'm wrong here, but the correct size in meters affects more than just "resolution", It's also used evaluate the erosion and other algorithms, which means the size and scale is important to correctly replicate the physical phenomena. If you're simulating a terrain with correct size and scale, the result will make much more sense than just keep bumping values up and down, not understanding why the value range doesn't make sense.
