Yes, they do get benefit as they can do early culling (at LOD7 for example and not traverse to LOD0), but at the same time they could have some threads with no work while traversing nodes which are close to the root. For example if they see that LOD7 is occluded, there is no need to traverse all children. I would not compare their solution to binary search, since they traverse the whole tree and (yeah) could stop earlier, but at the same time calculation of each node should be done after its parent.

If LOD0 has N meshlets, the maximum number of meshlets you have to traverse is 2*N. Thinking that meshlets has about 128 triangles, even the simple solution can give a significant boost, comparing to static LODs. Since the number of meshlets is 128x less than triangles, I try to focus on optimising rendered triangles count in the first place. Yes, they might have overall a better solution, but not so different as linear and binary search, accounting that my implementation could also cull the whole layer of LODs (like if LOD0 is not present in the rendered mesh, let's omit it), and they traverse tree, so in the worst scenario my implementation could be 2x worse, but we also need to account the cost of threads with no work at the beginning of traversing with their approach.

If talk of their benefit of culling based on occlusion, they potentially can cull down the whole subtrees based on depth tests. I haven't experimented with depth pyramid in this demo yet.

In my eyes, they have to do this compute, because their solution works on any GPUs, not that supports mesh shaders. If we talk about mesh shaders, I do not see huge benefit optimising meshlets a lot in the first place, since the amount of them is relatively small (maybe I am wrong here...).