In part the confusion here stems from exactly what we mean when we talk about an an Exposure. Fundamentally, that's a data structure in the LSST stack which provides a combination of a data image, a mask, a variance plane and an appropriate WCS. Since it's convenient to be able to read and write these Exposure s from disk, we provide utility routines which can serialize them to FITS. The on-disk format of that serialization isn't well documented, and I'm not sure to what extent we'd regard it as a stable interface. In practice, though, there's nothing too obscure going on, and that means that when you pass a FITS filename to the ExposureF constructor, it does a pretty good job of figuring out what you actually want from the data, but it squawks a bit to let you know that something out of the ordinary is happening.
The much simpler interface which I think we do reliably support for reading external data from disk is to simply read it as a FITS image. That makes minimal assumptions about the structure of the data, and should work with basically whatever you throw at it. Once you've got the data in memory, you can then use it to create an Exposure (or a MaskedImage, or whatever). For example, I think you could avoid the warnings above by replacing your call to afwImg.ExposureF(fileName) with
exposure = afwImg.makeExposure(afwImg.makeMaskedImage(afwImg.ImageF(filename)))
Note that this will create an ExposureF which doesn't have a WCS attached – if you need that, you'll need to load it separately from disk and include it in the call to makeExposure. Ultimately, that could end up being a lot of typing. The goal of this issue is to provide a more convenient method.