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).
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.