I can see where a subscriber list could be useful, but it sounds like from these use cases a subscriber count might be more useful. I had a similar case where units would publish status updates every 15 minutes for regular logging, but if someone was watching that unit it would publish every few seconds. I did it with a control type message, but thinking about it a subscriber count would work better.
However in my case I would typically always have a single subscriber that was simply putting the data into a database for historical reporting. You guys got me thinking and here's the design I would use(and may go back and fix my own code):
Decide subscribes to <device-id>/listening/#
Listener connects, and publishes a retained message to <device-id>/listening/<topic>/<client-id>, setting a LWT to clear the message.
Device keeps a count of listeners, and starts/stops(or increases frequency) based on that. I'm pretty sure it wouldn't even need to keep track of the individual clients. Just add one if there's a body, and remove it if there isn't. Assuming that it resets to its idle state when disconnected, or is a non-clean session(so it doesn't miss the removal of the retained message while disconnected).
That way you could have passive listeners that don't trigger device behavior changes without cluttering up the device code.
-Darren