This is where I get lost, and where I suspect there is still a mis-conception.
The TRC from the output ICC is not an invention of the ICC-based CM, nor something that is supposed to have an impact on the color rendering.
If you have an sRGB display, then the display expects input values to be encoded with the sRGB TRC. However, this is prevalently for the sake of efficient bit allocation. More recent display formats use different encodings, but conceptually they serve the same purpose. The display hardware will internally invert the TRC and make sure that the propose light intensity is emitted by each of the pixels so that colors are reproduced accurately.
Hence, you would want to bypass the TRC from the output ICC only if wanted to push pixels directly to screen without further color management.
Moreover, the DT Filmic module does not even see the output ICC, because the last step is a conversion from linear ProPhoto to CIELab. Then the module is completely agnostic with respect to where the pixels go further up in the pipeline.
What if they are been sent to a printer? Should one re-adjust the target gamma accordingly to what is in the printer profile?
Let me give you a simple example of what I am trying to explain. Here is a simple test in PhF, where I first apply a power correction with exponent=0.5, and then a second power correction with exponent=2.0. The net result is a no-op, because the two exponents are one the inverse of the other. Now let’s see what happens when the the first power correction is applied to the luminance channel and not to the individual RGB channels, while the second power adjustment is applied to the individual RGB channels. Notice that this is basically what the DT filmic code is doing, if we put aside for a moment the S-curve.
This is the input image in PhF:
This is the result of the sequence “exponent=0.5 applied to luminance + exponent=2.0 applied to RGB”:
Now, here is the input image in DT:
And this is the Filmic output with contrast=1, target gamma=2.0 and preserve chrominance activated; in order to compare apples with apples, I have disabled the luminance-dependent desaturation in the DT code:
Notice how the increase in saturation is very similar in PhF and DT?
Once more, this is nonsense in my opinion, unless you want to completely bypass the display color management and push pixel values directly to screen. The “output profile TRC” simply describes what the display hardware expects in terms of encoding of the input data. In a correctly set-up CM environment it has no bad side effects on the color reproduction, instead it guarantees that pixel values are properly interpreted by the display hardware…