Both, actually.
Lumen uses the surface cache for lighting in reflections which is essentially just a low resolution texture that is projected at pre-computed directions. Black areas are areas that are missing surface cache coverage for one reason or another. It is not cost effective to try to reach 100% surface cache coverage so pretty much any complex mesh will have some areas that will be black in indirectly lit areas of reflections.
Those black stripes on your mesh are typical of when you use a two-sided material on geometry that should not be two-sided. This is the first thing I would double check if I were you. Sometimes they’re just unavoidable though.
If you enable hit lighting for reflections, then Lumen will use the surface cache only for indirect lighting. Direct lighting will be evaluated according to the material properties. This will improve the reflections in directly lit portions of the reflections, but not in shadowed areas or in areas that are primarily lit by indirect lighting.
You can improve the quality of the lighting for the surface cache (at the cost of slower lighting update speed) by increasing the amount of frames the surface cache accumulates radiosity for (r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated). This however will not fix any areas missing surface cache coverage, and lighting will be less responsive to changes (so if you try to turn a light off, its lighting will fade out more slowly.)
You might be tempted to think that using hit lighting for GI (new option in 5.5+) should fix this (at an obscene performance cost) but in practice it doesn’t, Lumen still seems to maintain and use surface cache for indirect lighting in reflections even when set to use hit lighting for GI.
Regarding the mesh itself, Nanite is capable of drawing and rasterizing far more geometry than hardware raytracing can actually process at a reasonable speed, in order to deal with this Nanite generates a lower resolution proxy mesh (the fallback geometry) to use for the hardware raytracing representation of the scene. Think of it like an LOD that is used for hardware raytracing. This is the mesh you will see in reflections when you have hardware raytracing enabled.
Because creating LODs is tedious and time consuming work, Unreal tries to generate one automatically using edge collapse decimation, and it tends to look like crap on any man-made object. You end up losing straight edges and consistent shading.
In other words this is a problem with the mesh, but not your mesh… it’s an issue with the fallback mesh that the engine generated. Just like for a regular LOD, for best results you can make and import your own fallback mesh.
As you’ve discovered, another way to fix this is by simply setting the fallback relative error to 0. This means that the generated mesh will be the same as the Nanite mesh… which defeats the purpose. By setting the fallback relative error to 0, you’ve told the engine to use the full resolution Nanite geometry for hardware raytracing which wipes out the memory benefits of Nanite while also increasing the hardware raytracing cost. Not advisable if you care about performance.
The TL;DR here is pretty much: Mirror reflections are still an unsolved problem. There are things you can do to improve it, but they are not perfect by any stretch.
