The biggest problem I remember was that XMPP was (is?) about message delivery, while what we really wanted was "synchronized message log".
So multi device did not work: One device was designated "active" and would receive the messages, others would not.
There was no history sync of any sort: If you had checked messages from home, they would not appear in your work computer's history next morning. If you replied from home, you won't be able to see your own messages at work PC.
Anything mobile (mobile phone, laptop in coffee shops) was also unusable -- you cannot start app and catch up on all missing messages. You had to be online to receive them.
For mobile access, I ended up doing custom Pidgin plugin (in perl!) which would export messages to text documents served over webserver, and then I'd visit that page from my phone to read the messages.
---
I still don't know what was wrong with that system, was this our admin not spending enough time on the server, bad documentation, or bad clients -- but this did not really matter, this experience really destroyed XMPP brand. We used Google Talk and Slack later, and they were "just working", no batteries required, no messages lost.
The funny thing I believe that Google Talk might have used XMPP under a hood at some point -- but it worked really well. So it is definitely possible to build working, feature-full things on XMPP... you just had to extend it and use it as underlying layer. Kinda like TCP and IP in a way.
You're spot on with your memory of early XMPP's behaviour. While it was one of the first messaging protocols to support simultaneous login, the focus was originally about routing messages to the right device. In the context of that period in tech, that was excusable and even desirable. As people got more devices connected, more permanently yet intermittently (i.e. smartphones), it stopped making any sense. We switched to a broadcast-and-sync approach, but it took a long time (years) for all the long tail of smaller internal deployments to roll that out (if they ever did). Another big issue was that one of the most popular clients was Pidgin, which ran into developer resource issues around the same time and still hasn't caught up yet. To many people though, this was XMPP.
I'm hoping a new generation of XMPP implementations can solve these kinds of issues, which was what inspired my "Products vs Protocols" [1] talk/article a couple of years ago, and is why I work on Snikket (and we have many happy users who are both new and not-so-new to XMPP).
All of these companies chose to kill federation for their own advantage, making the world poorer.
Controlling spam inside a closed network is drastically easier than controlling spam in an open network, because in a closed network you have lots of ways to make bans stick, whereas in an open network you really can't. Faced with the choice of building a massive Gmail style heuristic spam filter in which basically all the messages it was processing would be spam, or, just turning off federation, they went for the latter. It was probably the right call. Very few people even noticed, let alone cared. The idea of an SMTP-style global network of federated chat servers was dead by that point.
Google was kicked by the other servers out of federation due to their abandonment way before Google turned it off. And it was always flacky to begin with, specially since they also started dropping 3rd party clients (and for that you can't blame spam...).
And even if one argues that Google ignored federation because of spam and/or low usage, OP's claim that they did that "for their own advantage, making the world poorer" would still be valid.
I'm not saying they didn't have spam problems, but that's the kind of thing they certainly had resources to solve. They already had such systems due to Gmail, and even independent XMPP operators have a pretty good handle on XMPP spam these days without even a fraction of the resources available to Google. It was more a matter of priorities du jour for the company.
Independent XMPP operators don't have anywhere near the spam problems Google has/had. They're just far less appealing targets.
https://www.slideshare.net/InfoQ/how-slack-works
It may have subsequently turned into something more like how IRC servers work, but early on it doesn't appear to have been.
The environment outside of major providers was (it definitely is) kind of janky. If you can set up a server application it's not hard but it's not exactly easy to get started, or get people on it without handholding (from my own experience).