Indeed! However, some things have changed since XMPP initially came out. For example, Message Archive Management (and equivalents in the PubSub/MIX specs) has been introduced so that messages can be stored reliably, reducing the need for presence. Multi-client usage has also grown, especially with mobile computers ("smartphones") with Internet access everywhere. Then, we now know and have proof that metadata leaks are used to actually harm people and that presence information can be used to establish correlations between several identities.

To be clear, I'm not arguing against presence being supported on a protocol level. However, i believe the protocol and clients/servers should support the usecase where presence information should not be leaked: that people see a message when i send it is fine, but that they know when my computer is online/offline, or when i'm "away" is way too much metadata leak for a privacy-conscious usecase.

My favorite way to deal with that would be to have a "private browsing" mode on IM clients. So that you could turn on/off privacy settings globally with a single switch. I'm guessing a lot of people would choose the "private" mode if prompted for it on first run. I know i would :)

It is quite possible not to send presence information at all. I'll say more, we're working on an 'omnipresence' protocol that will advertise only the desired status to the external contacts, and will not leak per-device presences.

This Presence thing works well for always connected clients (desktop), but becomes a huge problem on clients that can't be always connected (iOS ones).

Desktop is not always connected. People turn it off, or suspend it to save on electricity bills.

From the point of view of xmpp development, it is always connected. Thing is, xmpp session start is a very costly operation. Desktop generally does it once and has it easy from then on. iOS device connects every time a user opens an app. By the time it'll finish receiving presence information, a user will already close it, and the OS will terminate app process.

Unless the protocol is connectionless, the server will always know at least the user's online status.

I have to use Slack for work, and the way I solve this is to have my client not send typing notifications, and have the client running on my server and repeatedly sending activity notifications all the time, so I always appear online and present to Slack servers.

I can prevent Slack from knowing when I'm really connected only by being connected all the time and always pinging my activity status in periodic fashion 24/7, so that from PoV of the server it's not possible to determine anything about my actual activity or online status on my workstation, because there's no relation to real-life status.