Matrix do have a much bigger marketing budget than the XSF, it's true. They fly their employees all over the globe, and appear to have a constant stream of FUD on tap about XMPP, presumably because it's their strongest competitor. Last I saw, though, it's got a thumping great single-point-of-control in the middle, firmly under their corporate grasp. Nothing too critical, though, only your identity. (Looking at the FAQ, the "Can I run my own Identity Server?" question is simply missing, but I can answer that one: No)
XMPP's primary distinction is that all services are fully partitioned by domain. The only shared state - and I use this term very loosely - is in subscription data, which is long term. (By subscription data, I'm intending to mean the roster, pubsub, and also MUC chatroom occupancy). Matrix attempts to share considerably more state, acting much more like a single chat service scattered across multiple servers, but due to the centralized and privileged identity servers, there's a significant loss of autonomy in the system. Important to note, an XMPPservice on a single domain can be spread across multiple physical servers, fully sharing state, in which case you're well into the territory of vector clocking and CAP theorums, but that's an internal matter for your service and doesn't affect the inter-domain federation at all.
In layman's terms, you can run an XMPP service without reference to any external system - although federation would need you to reference DNS. Running a Matrix server leaves you somewhat under the control of Matrix, which despite appearances is just a branding for a commercial outfit.
Well, that, and XMPP is an open standard according to a definition we didn't just make up as part of our marketing. (see OpenStand.org)
So first off, it may be useful to note that when looking for a universal, interoperable standard for text chat, the armed forces around the world went for XMPP. This based on its reliability and handling of low bandwidth situations (much, much, MUCH lower bandwidth than mobile). So when you say XMPP doesn't support your notion of an MVP, it's worth noting it really is just that - your notion. That doesn't make you wrong, but it may be that your focus is different from other people's.
And as a second point, when considering writing something on the web, you (thankfully) don't have to implement JavaScript. Or HTML. Or CSS. Or, thank heavens, HTTP. Do you even know what happens in HTTP? Clearly not, otherwise you'd be a gibbering wreck - it's about as badly designed as a protocol can be and still work. And don't get me started on TCP; nobody gets that right.
So really, if you're implementing something using XMPP, please don't leap in at the low level - just use one of the many libraries for your chosen platforms.
Next: Unique message identifiers are an interesting topic, and you've referenced several XEPs that don't address the problem. One issue is that what's needed varies in different situations - generally, a short-term scoped identifier is good enough, but it's fair to say that's not always the case. The tuple of is good enough for this, though clients aren't mandated to send an identifier. It's not even clear to me that we need global stable persistent single-valued identifiers, but despite there being no use-case explained to me where this is required, I'm aware it's a popular solution some undefined problem.
Worth noting, too, that XEP-0198 and XEP-0184, though often confused as addressing the same problem, actually address entirely different ones. '198 addresses link reliability, tackling the two generals problem. '184 addresses end to end acks. You end up with acks in both, but 184's can be out of order, and 198 allows session resumption and retransmissions, which addresses the same cases you identify with vector clocks between domains. Your library should handle all this for you, and just note if a message is lost.
Carbons you have entirely wrong, sorry. It does not involve "re-sending your messages back to the server", it just allows non-priority clients to get copies of all messages. The only oddity is that the copies are just that - they're not duplicates. This allows the client being copied to identify that the messages are going to a different device. Which device is usually based on "priority", though different servers can do things slightly differently. Despite this, it doesn't have anything to do with message traffic. And it's not random.
However, clients typically respond to the device which sent the message - but if the sender has moved devices, they'll get a carbon. And yes, there is a massive "if supported" right there, but there are desktop clients that do.
In fact, we don't handle the "every device has the same view of the universe" concept - you're right - we handle the "every device knows the state of every other device". It's functionally identical, but a slightly richer view.
So, let's rewind.
The XSF doesn't write software, though there are many libraries out there. We're working on Push, mostly to cover Apple's platform where long-running sessions are prohibited - this despite the fact that on Android, clients like Yaxim or Conversations don't excessively use power.
The XSF also doesn't do the levels of social media advertising that Matrix does. This is becoming increasingly problematic for us as a community, because Matrix are explicitly targetting XMPP with things that are simply untrue.
Most of the problems you identify are actually solved at the protocol layer. They really are. And it's not as bad a solution as you imply, either - in fact, the solutions to multi-device messaging and archiving are pretty good, and more based on "every device knows about the other devices" rather than "every device is treated identically", which is interesting in and of itself.
Oh, and when I said low bandwidth? XMPP is routinely used over 2400bps SATCOM links with 30s latency, but it'll run lower. Try 9 bits per second, half-duplex, with 2 minutes link turnaround.