I have created an issue in our bug tracking database for this (MIRAST-16423). I will make a minimal change to the native TIFF driver code to fix the issue in this particular case.
The problem arises because TIFF files can change the order in which bits are stored in a byte. The designers of the TIFF format did this to make sure it is as difficult as possible to correctly read the files.
Our driver knows about this and reverses the bit order when required. In this case, the bits do need reversing (this TIFF file is unusual in a number of ways). However, this results in the wrong outcome and re-reading the TIFF library documentation carefully implies that we should not have to manually reverse the bits because the library function we call is doing it for us. But we added the code to reverse the bits because other customers files were not working, so there must be scenarios in which the TIFF library does not do the right thing and we need to do it in our driver. Clearly, this is not one of those scenarios. The question for me is - what are the scenarios in which our driver has to intervene? This will require research.
In the meantime I will make a change that makes it work for your files, assuming they all have the same structure as the one you supplied. This will go into the version 17 patch for December release.