this ticket seems to be a bit vague, in the sense that, as I outlined in
INT-3775, a way to receive MTOM attachments properly is to use a MarshallingWebServiceInboundGateway properly configured with a MTOM-enabled (un)marshaller, so MTOM support (at least for the receiving part) in SI actually exists. I have not yet adventured myself with responses, so I can't provide any feedback on that.
What I saw is the inconsistency with the use of SimpleWebServiceInboundGateway followed by an unmarshalling transformer (which uses the exact same MTOM-enabled unmarshaller of the first case) in place of the MarshallingWebServiceInboundGateway.
Honestly, I didn't try the extract-payload attribute (it was not mentioned in the reference documentation), it may be interesting to see if it works. I'll try as soon as possible, although I doubt it will work with int-xml:unmarshalling-transformer, which I suppose expects just a Source instance.
One thing I was thinking about is that, if a plain Source on the request channel can't carry the MTOM attachments by itself, probably finding a way to support unmarshalling of a whole WebServiceMessage with a dedicated tag wouldn't be worth the effort: once again, just a good documentation on this topic could be enough to guide the user on how to do this task (i.e.: properly handling incoming messages containing MTOM attachments).
On the other hand, if some smart way to "convert" the WebServiceMessage into a "plain" Source with (inlined?) attachments, processable by a simple int-xml:unmarshalling-transformer, could be found, well it might be more interesting. But I really don't know what this may mean in terms of performance and memory consumption (the whole attachment should probably be put on the request channel in any case, so I would say it wouldn't make any difference... but I really don't know how these things are handled at low level).