Several times in UE4 documentation, it refers to LUTs as only working in display-referred space (such as Rec.709 sRGB) and are thus unsuitable for HDR workflows.
However. I can take a pre-tonemap (scene-referred) ACEScg EXR out of UE4 into resolve, set resolve to ACEScg configuration, do color grading, and generate a LUT from resolve.
Could you not, theoretically, create a LUT-based pipeline where a colorist gets scene-referred values, gives back a LUT based on scene-referred values, and then the engine takes the LUT, does the transformation, and then tonemaps to whatever display it needs?
In short, I don’t see why using LUTs is inherently impossible for HDR. Does anybody have more information?
Scene-referred linear LUTs are not impossible, they just aren’t supported in UE4 right now. This workflow is exactly what Activision did for WWII, even though they used Nuke. It’s just as simple in Resolve, although the working project space probably wouldn’t be ACEScg. There needs to be an display LUT with the minor ACES RRT modifications by Epic, so what you see in Resolve/Nuke is identical to what you see in game.
As you’ve noticed, they require extensive knowledge of 3rd-party programs so I don’t see it becoming a priority anytime soon. Also, Rec709 is display-referred 
You’re right about the workflow though.
Exposed, but pre-tonemapped image -> Resolve with display LUT - > grade and export(without display LUT) -> insert new LUT before tonemapping, replacing the existing scene color
@rosegoldslugs Thanks for the reply, and yes I noticed my typo but couldn’t edit it due to being new to the forum. 
One more question I have is that if colorists are working in pre-tonemap space, they aren’t really seeing the final image, since they can’t see how their changes combine with tonemapping. With in-engine color grading tools, the engine could, I guess, give the colorist a post-tonemap image, but have the color grading changes inserted before the tonemapping, and so the colorist can see the post-tonemapped image with color grading applied and yet have it be applied before display-referred transformation. I wonder if there’s a strong preference or advantage there.
That’s exactly how the in-engine color grade works right now actually. You see the final tonemapped image in your display color space and gamma, but the actual color wheels are affecting the pre-tonemapped image. That same concept is where the display/viewer LUT comes in with external tools like Nuke and Resolve - you work in one space, but view in another.
The only issue I’ve come across with this workflow is the perceptual differences between SDR and HDR when it comes to colors at brighter intensities, or colors transformed to a wider color gamut for HDR in which you have little control over with SDR and HDR being identical in every way except the tonemapped output. But this also applies to the in-engine color wheels, so really it comes down to working in whatever setup you prioritize.
Edit: Here’s the talk I mentioned earlier if anyone is interested. DD2018: Paul Malin - HDR display in Call of Duty - YouTube