Well, there seems to be a lot of issues and confusion with the new tonemapper, also in regards to how emissive is handled.
I think that Epic still needs some time for refining this and also, you basically need 2 different approaches for tonemapping when qworking on a SDR screen but you want to output HDR in the end.
Depending on how you do the SDR mapping for that content, results can vary from really bad to kind of okay…but it definitely is something that doesnt feel fully finished in Unreal just yet.
Besides that, ACES tonemapping is known for its high crunch factor of blacks and whites and personally, I dont like the look of it too much.
You can see a couple of comparison shots here that further illustrate the problems I see with the ACES standard, but time will tell how Epic will tackle all of these.
http://forums.odforce.net/topic/25019-hable-and-aces-tonemapping/
If you check the provided images here, you can see that ACES in almost every instance provides visually less pleasing results 
Cheers!
EDIT: I think whats needed is a seperate tonemapper curve for the SDR output since thats what most people use right now anyways. We basically do something similar where we map the HDR stuff into SDR for working with non HDR screens and that tonemapper is configured in a way that basically makes things look correct when working in SDR and then when you output HDR, it takes care of the conversation and everything just works. So I guess that Epic would really need to upgrade their display mapper for this to work properly, but then again…all of this stuff is so new that I havent wrapped my head around it completely :S