First of all: what would be the reason for processing RED footage with a F55 IDT, or BMDCC footage with any LogC IDTs? And why exporting a QuickTime or a DNxHR file in this way?
I have the impression these tests are done treating ACES Input/Output Transforms like camera/viewing LUTs, but one has to consider the whole system and that, despite it is not a “rigid” framework, it can still be used wrong and produce poorer result than a non-ACES workflow. I mean: nothing prevents to use the system in that way (considering ACES just like LUTs), but “you might get wet”.
When an ACES-aware software processes raw footage without the possibility to explicitly set an Input Transform (IDT), that automatic process is exactly the IDT — at least if the software does it according to ACES specifications. I believe this is what DaVinci Resolve does and it’s fundamentally correct not having the ability to change an Input Transform as long as the software picks up the right one for you (by parsing the source-file metadata).
I believe (but this is just my assumption) that the reason why Resolve allows you to change the Input Transform with raw footage from the Sony Fx5 camera is because Sony distributes the IDTs in the form of CTL files (they are freely available from Sony Cinealta’s website as well as from the official ACES repositories), while other camera vendors provide IDT capabilities embedded in their own software, or in their SDK for product partners. Both RED and Sony provide the SDK way, but RED does that exclusively (i.e. it does not provide IDTs as CTL files)
So Resolve implements the Sony Fx5 Input Transforms in two ways (via external IDT CTL/DCTL and via SDK). So in case a camera vendor (e.g. Sony) changes/improves their IDTs, users can replace them by switching to the new (D)CTLs in Resolve, while for SDK-only camera vendors, the whole color-processing application must be patched or upgraded. I repeat: this is my personal opinion to the original topic question.
As goes to the DNxHR export of footage “without the ODT” to re-import in an application “without IDT”, I should really warn against running these processes unless one really understands what a particular product/appliance is doing with the color management. ACES framework allows to import and export footage without Input/Output Transorms (if it’s already nativevly ACES2065-1 at the input/output end), but the products implementing this could do other things as well to the color management if the workflow is not done the proper way. For example I am a bit worried in using DNxHR or a QuickTime container format since they don’t have (yet) proper metadata that can make a software product acknowledge the required input/output ACES colorimetry.