Greetings all. A little bird poked me at this thread and hopefully, after having communicated and confirmed the following with Sean Cooper (Thanks Sean) at SPI, I can clear things up a little bit.
The issue is that in terms of order of operations, Looks in OCIO are designed in a very particular fashion that OCIO executes. They may appear to be similar to the input / output nature of data with regular transforms, but they are in fact not. This has to do with how pipelines would apply looks.
The key point to remember with looks is that OCIO will always assume that the data is in reference, and then, upon finishing a look transform, will return the data back to reference. In this case, we know our reference space is using a scene referred linear format. We will ignore reference primaries for now as they are a distraction.
When we enter into the Filmic look transform, we can see that the process space is indicated as being the Filmic Log Encoding. Given that the look assumes that we are in reference, and our reference is linear, OCIO will apply the Filmic Log Encoding transform chain to the data for us.
Drilling down into that transform, we see an allocation transform which takes the scene referred linear data to a log2 encoded nonlinear format that covers 25 stops of data. Then it routes through the desaturation transform, and from there, it ends up scaled to the final Filmic range of 16.5 stops.
Now the data is in the process space and we are returned to the look transform to apply whatever its payload is. In this case it is a single nonlinear file transform of whatever contrast we have chosen.
At the tail end of the transform chain now, one would think that the data is simply returned to the buffer. However this is not the case. Looks are always applied on the scene referred data and OCIO will do its best to return the data to that format. In this case, that means that we now travel through the "to_reference" transform from the process space. This now takes the buffer and uncompressed the log2 allocation back to scene referred linear.
So how would we come back out of that look situation with a perfect 1:1 on the data? We would need to exit the look and roll our data through a Filmic Log Encoding! This would take the data and pass it through the standard input / output transform that re-encodes that data to the log2 explicitly defined by the Filmic Log Encoding transform.
The answer that suggests the order is odd is in fact correct, and hopefully this answer explains why; OCIO looks always assume scene referred linear data as an entry, and return the data back to the reference encoding.
Note: Do not do this unless you need to get to the display referred domain for some (rare) colour manipulation. If you mangle your data to a nonlinear encoding, you will break almost all manipulations including but not limited to blurring, overs, blending, etc. When doing work, use the view and leave your data in the scene referred linear domain for all work. This technique applies when you absolutely must transform your data to the nonlinear domain for file output or again, a (exceptionally rare) colour manipulation on the display referred data.
Hope this helps,
 The astute observer would note that rolling through the Filmic Log Encoding twice would apply the desaturation twice. This is correct. The result would still be 1:1 with what one would see using the traditional view / look transform however. In addition to this, given that the desaturation only begins at +6.0 stops above middle grey, only a half stop of data is essentially subject to this double up. The next iteration of Filmic will address these minor issues.