Ah, I think I see some of your logic here. So, you’re concerned that lumen performance tanks too badly when too many dynamic lights are on screen together?
As of right now, lumen is only an indirect lighting solver (although they are experimenting with lumen handling direct lighting as well). You are right in that lumen performance would degrade significantly as it’s handed more and more lights to process, but lumen is designed to pick the most important lights in the scene and only sample those to a certain limit (at least if they implemented the smarter sampling they said they would). Basically, instead of lumen costing more to evaluate GI from more lights, it’s instead limiting the # of lights that can contribute to GI in ways.
Pretty much all of this logic (the noise vs. perf. vs. light # tradeoffs) can be adjusted via CVars. For example, you could probably have more dynamic lights by having them noisier, or have fewer, but better-looking GI, etc. It’s all about what decisions you want to make performance-wise.
There may very well be good uses for mixing lumen with static lightmaps on lower-end hardware (cheaper dynamic outdoor GI mixed with very clean baked indoor GI), but between the VRAM management, the workflow limitations, and the divergent software paths, I could see it getting quite complex to manage