Sad, neither MongooseIM, nor ejabberd use proper Erlang/OTP SASL release system, so hot updates can be done with relup (http://erlang.org/doc/man/relup.html)
Smaller modules can be upgraded from Erlang shell, but it's seems to be impossible to update a server without shutting it down.
I'm not sure how you've measured how often hot code reloading is used? I use it for almost all of my production pushes.
However, I agree that it's generally hard to use it for third party software; upgrades would either become cumbersome because you have to follow the same piecewise upgrade process the developer followed, or the developer would have to do a lot of extra work to ensure upgrades between releases were solid; the recent addition of atomic loading of multiple modules would probably help.
Gajim [1] implements a lot of modern XEPs (directly or through easy to install plugins), including OMEMO. I don't know how well it works on non Linux systems (they provide Windows binaries at least).
It is worse, actually, because it uses GTK, and is only available on Linux and Windows (not macOS, although there have been attempts).
Most of the "big names" who provide modern and contemporary desktop IM apps deliver on the 3 platforms (Linux, macOS, and Windows), and use mostly web "technologies" (sometimes "pure browser", and sometimes with electron-like desktop "packaging")... so as a consequence, it is very native, indeed, but it is a generally consistent and continuous UX (user experience) between mobile/tablet and desktop/laptop.
Is GNU compatible and thus can run on all platforms (e.g. Windows via MinGW). Some features might require special handling for Windows / OS X (GPG, Audio/Video) and Linux is for now the "official" target platform...
Speaking of modern XMPP... Is there a way to have a shared history for a group these days? Say the server has three users — A, B and C. If A and B is chatting and C is not currently present in the chat, can C see the conversation that took place in the group chat when C was not present when she returns?
Yes and no. The only production-ready of such a requirement is "MUC light". Basically, it is a very simplified version of MUC, that does not rely on user's presence. It exists in the MongooseIM server, in Smack library for Android and in XMPPFramework library for iOS, as well as in Mangosta iOS and Mangosta Android, two free/libre/opensource clients soon to be released. So it is ok to develop a solution based on this approach.
I realise this isn't actually relevant to the article content, but it seems weird that the TOC doesn't contain links to the relevant section. I know it's pretty short so I can scroll through it quickly, and numbered so I can even just ctrl+f it, but I don't think I should have to do either of those things.
XMPP protocol is so open, that different implementations offer so distinct features, so the lowest common denominator barely includes sending messages to each other.
One cannot not say something is "so open that..." ;-)
But indeed, XMPP is open, very open.
And indeed the major clients usually rely on the old era's ways of thinking messaging... They a far from contemporary, not only talking of features, but also the UX (User eXperience) and the general philosophy.
Smaller modules can be upgraded from Erlang shell, but it's seems to be impossible to update a server without shutting it down.