That's not true.
We have implemented multicast during the Google summer of Code (See for example of the related patch: https://support.process-one.net/browse/EJAB-329).
It being test and optimised but works today if you apply the patch. It will be in ejabberd 2.1.
It is implemented in the server for multiple things, including pubsub and multi-user chat.
That's an improvement, however, after looking at it I must say that that's not multicast. This is multiple recipients for a message.
You shouldn't need to address the recipients, presence already involves people subscribing to your "presence channel". Thus your homeserver should know how to distribute the efficiently - for example by multicast. XEP-0033 just adds redundancy.
Multicast only works on either something as esoteric as the MBONE or on a local LAN/WAN. It isn't out there on the general internet, it requires too much state in the routers, so it never took off.
The original comment was not on transport level multicast, but on application level multicast. This is the one implement in ejabberd patches and thus works over Internet, not only LAN/WAN.
Transport-level mcast requires special routers..
Ah! No wonder I couldn't get the MBone videoconferencing stuff to work with Trumpet Winsock, years ago
The server knows how to distribute the message to multiple recipient and does that by itself. The client has of course nothing to do.
ejabberd does that automatically for presence, but also for Multi-user chat and pubsub.
It is implemented in the server for multiple things, including pubsub and multi-user chat.