I would like to second the argument of @iluetkeb about use-time complexity of multiple communication mechanisms, from a different point of view: I have a student working on developer understanding of ROS and the current variety of communication mechanisms, and the consensus about the persons being interviewed is that there are too many of them.
I am all in favor of keeping it simple, and implementation-wise, the original proposal using a daemon and the existing ROS communication mechanism looks very attractive to me. The daemon always runs and has the information available as a ROS service call, plus uses a topic to broadcast changes to the graph such that long-running tools are informed of this.
If later on it turns out that more is needed (e.g. REST API), this can simply be implemented as extra functionality on top of this layer.