euh, terrain doesn’t use HSDS, and it doesn’t subdivide (most current day engines don’t subdivide their terrains either), it uses a heightmap image that, prolly (going by guessing as my knowledge of unity and terrain in unity is very limited, going by what most engines do in this case) by the usage of mip mapping is reduced to lower quality depending on a (likely) bias + distance. Atleast that’s how it’s done in many game engines.
From some quick tests it seems to be even the case, as you can clearly see different terrain sectors and neighbouring sectors that are higher optimized are 1/4th the detail of the higher detail sector, a good indicator of mip-map optimization of the terrain heightmap. It’s a popular implementation, thou a bit old (doesn’t make it bad thou 
).
All data is already at the highest level, no subdivisions, it just optimizes itself into a lower level.
Making that system support spherical isn’t necessarily “hard” thou either.
edit: you can actually clearly see it doesn’t subdivide by setting the terrain resolution to 32 (set textured wire on), making some hills and then setting the resolution to 1024 and making the hills again. The clear density difference is easy to see, no subdivisions, just heightmap mipmapping optimization.
The real reason this system usually is confined to planes is because of the heightmap being a greyscale. It only supports values for one of the 3D coordinates (in unity’s case the Y coordinate), but it’s pretty much lossless for that one coordinate, which is great! Technically you could just multiply the heightmap with the worldnormals of a sphere and get the heightmap working for a sphere (or any shape really), but you’d also need a UV mapping scheme that works great for spheres (to counteract too much detail at the poles etc…) and a sphere generation algorithm that doesn’t waste triangles where it doesn’t need it, like at the poles again.
That’s the hardest part of getting a sphere shape to work, the blatant amount of waste in the system and the visual errors it introduces.
Poles usually get effed up with spheres and algorithms that counter the triangle waste at poles, end up not being detailed enough for the detail in the heightmap or the sphere ends up being too detailed for the heightmap (again waste), I don’t know any algorithm that works perfect for spheres in this case atleast. Someone can point me to a source with a good algo, I’d definitely be interested! (no sarcasm or anything implied here, I truly would be).
And generally this system was designed for planes, not for other shapes