Some considerations which might or might not matter.
I am rather certain that you can't use WCF, MSMQ and MSMQ Transactions. You can investigate yourself but I believe there is a fundamental problem in terms of receiving them. Basically they can be sent ok (with a transaction), but when receiving them there is no assurance that the transaction is preserved. (I can't remember how I came to this conclusion.)
MSMQ has a hard 4 meg byte limit per message. Between overhead and unicode (not optional) that can reduce the maximum message sized to less than 2 meg (bytes.) Microsoft technical docs state they have no intention of changing this limit.
Despite claims to the contrary WCF/MSMQ does not support a streaming operation. So the message must always be less than 2 meg.
MSMQ uses magic routing which is great when it works (when you get all the ports/permissions right) but is extremely difficult to figure out otherwise. And because of that messages can take a long time to arrive at the target, for example hours.
MSMQ at least on OSes before 2008 (and maybe that too) uses by default a single file with a 2 gig limit for persistence. MSMQ will crash if that file fills. And there is no way to monitor problems via the MSMQ API (maybe there is something in WMI.)
Most of the standard MSMQ 'queues' use Active Directory. If Active Directory has problems then MSMQ will have problems. If you use options to exclude Active Directory then you CANNOT insure transactions are in use. See next note.
If one queue uses transactions and the other end doesn't, messages just disappear.
MSMQ failures can result in MSMQ exceptions which have a enum which indicates the type of error. The problem however is that API can end up returning a value, via the enum api, which is not a enum. Basically violating the contract of the method.
MSMQ queue permissions and application permissions must match. Which would seem obvious. However if they don't match then it returns non-helpful errors. Such as telling you that the queue doesn't exist (even though it does.)
MSMQ is supposed to support multiple clients consuming from a single queue. However someone I know (but not me) ran a test that suggested performance was significantly degraded in such a scenario when transactions were in use. Developing around this is complicated.
I can state that I built message streaming using chunking to break a larger (bigger than 4 meg) into pieces. It was extremely difficult. Especially since I was attempting to support multiple clients (see above limitation)
MSMQ is tied to the OS. This of course means that if you want to upgrade from, say, MSMQ 3.0 to 4.0, then you must upgrade the OS.