As of a handful of months ago, UE_main received support for lumen reflections in lightmaps, so that is currently a solved problem for anyone interested.
Unfortunately, lumen GI and lightmaps can’t really work together due to a handful of issues, but it’s more fundumentally down to what would make sense from a systems perspective.
Lumen’s screenprobegather evaluates arbitrary scene radiance, from analytical light sources or emissive objects. If it is in the lumen scene, you’re paying the cost of evaluating it, even if you don’t ‘need’ it lit. Essentially, it’s hard to pay ‘partial’ costs for lumen features. Lumen reflections work because it can use the lightmap to terminate reflections with GI, but for lumen GI itself, it needs a surface cache and parameterized scene.
Basically all of that means that having lightmaps and lumen work together, even if it was feasable, is very unlikely to actually run better. Lightmaps eat up a lot of VRAM even if streamed (generally), and they constrain the scene to be static. Lumen’s various atlases and buffers also eat up a lot of VRAM, and require a fair bit of computation to boot. It’s not that static lighting and lumen can’t be combined together (lumen does this by sampling material AO instead of evaluating it at runtime), just that it wouldn’t really give any advantages to do so.