TL;DR: Increase “LOD 0 Screen Size” on your landscape component, and this will result in lower polycounts on HLOD landscapes
(But I’d recommend reading the explanation, as it gives a better sense of what’s going on)
Okay, so, after a lot of experimenting and digging through the engine’s source code, I’ve managed to come up with a solution for this. The above fix works fine for the Open World demo map, but it wouldn’t work on my actual game map.
------------------------------------- Diagnosis -------------------------------------
The issue actually lies in the Landscape’s LOD screen size settings. During landscape HLOD generation, the engine picks the LOD of the landscape component to use as the source based on these screen size values.
To understand the fix, we need to understand how landscape HLOD generation works. The HLOD Builder automatically assigns the “LandscapeHLODBuilder” class to any landscape proxies during the HLOD building phase. So the step mentioned in one of the replies above where you have to set the Landscape HLOD Builder as the parent HLOD layer, isn’t actually necessary. The engine automatically makes the Landscape proxies use this layer for HLOD generation.
To generate the HLOD, it essentially works out how big (in terms of screen size) the landscape proxy will be in-game when it turns into a HLOD at distance.
The problematic high poly HLOD meshes are created because the HLOD generator decides that EVERY TILE needs to use LOD 0 for the HLOD. To explain this, I printed out some logs:
This was during HLOD generation on a landscape with settings:
As we can see, during HLOD generation the engine knows that the landscape’s max LOD is 5. It then evaluates that the LOD needed for the HLOD mesh is 0. To reach this value, it calculates that the landscape proxy will have screen-size of 1.26 when it switches into a HLOD, and for screen sizes over 0.5, the landscape should be at LOD 0.
THIS IS WHERE THE PROBLEM LIES, as 0.5 is the default value, but is far from desirable in maps with large landscape tiles.
------------------------------------- Solution -------------------------------------
WITHOUT EDITING ENGINE SOURCE:
If you increase “LOD 0 screen size”, then the engine will pick a lower LOD of the landscape component to generate the HLOD mesh. This is how you fix the issue.
I can’t give exact values that will work for your landscape, but by tweaking, generating HLODs & checking wireframes, you can hone in on the ideal settings for your landscape.
After editing mine, we can see that during HLOD generation, the algorithm now picks LOD 2 as the HLOD’s source instead of LOD 0 (reducing the generated HLOD by over 200k verts)
This method is good, but I can’t seem to get the generator to choose a LOD higher than 2 without decimating my landscape’s quality. So this is where the source code solution comes into play…
WITH EDITING ENGINE SOURCE (More control):
Alternatively, if you don’t want to mess with your landscape’s LODs, an easier fix is to force the HLOD generator to use a certain LOD of your landscape. This requires a source build of the engine, and is done by changing the return value of ComputeRequiredLandscapeLOD() in LandscapeHLODBuilder.cpp to the LOD you want.
For example, if I want to force LOD 4 for all Landscape HLODs:
Replace:
return RequiredLOD;
With:
return 4;
This will fix the issue without affecting your landscape’s LOD streaming. However, you need to make sure that your landscape actually has this many LODs. Alternatively, you could use:
return InLandscapeProxy->MaxLODLevel;
To return the highest available LOD, which is safer. (need to also make sure MaxLODLevel isn’t set to -1)
Hopefully this wasn’t too long-winded! 
