I see. As for your concern about the use of persistent occupants, sometimes they are useful.
Chat room occupants may want to know what was said in the room during the time he was offline. Although rejoin will bring some chat history, but what if the number of messages he missed exceeds the number of chat history messages that was configured to send to newly joined occupants? Certainly some messages will not be seen by him.
In addition, the chat history presented may also contain many messages that had already been read, which may result in duplicate chat record on the client. Although it can be prevented by hard-coded filter on client side, but the effort can be readily saved if the server can provide persistent occupantship.
So, are we speaking about the same thing? “You mean you want for a user to stay in the room when he is offline?” If so, then http://xmpp.org/extensions/xep-0045.html
17.1.2 Ghost Users
Deployment experience has shown that sometimes a user can appear to be an occupant in a room even though the user’s real JID has gone offline since joining. Such users are called “ghosts”. To help prevent ghost users, a MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (in this context, the delivery-related errors are , , , , , and ). A MUC service MAY also use XMPP Ping  or similar methods to periodically check the availability of room occupants. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.
This suggests that offline (ghost) users should be removed from the room’s occupants list. And i think Openfire’s (and other xmpp servers’) MUC service is doing this. I haven’t ever seen offline users in the group chats.
Btw, if a client goes offline, what’s the point to keep it in the room? You can modify your client (if you can) to automatically rejoin rooms after reconnecting to a server.