Remember that anyone can subscribe to those messages, multiple anyones. You don’t need openHAB to sit in the middle. The MQTT broker is a service completely independent of openHAB.
You’d generally only need to publish from openHAB stuff wholly generated within openHAB - instructions like “turn on”, or some calculated value, etc.
If your dashboards or whatever can get the message straight from the horse’s mouth, do it.
openHAB can listen in as well of course, but doesn’t need to re-publish it.
Internally to openHAB, the general model is that an Item represents some device.
It’ll have a state, a condition (typically messages from a real device will be processed by an OH binding, like MQTT or zwave, into Item state updates).
Rules or users at the GUI can issue commands, “do something” instructions, to Items, and a binding can process those into external messages (like MQTT)
As you can see, there is no path for OH Item states to be reported to external devices/services.
That’s okay, openHAB allows all sorts of customizations so that there are several ways to get an Item state reported out to MQTT. Which is the most appropriate way depends - what is the original source of the data? How many are involved? Does the raw data need massaging or conversion before publishing? etc.
At the simplest, there are features that can attach to an incoming sensor report from say zwave device, and auto-route that to MQTT to be treated as though it were a command i.e. trigger a publish message.
At the more complex, people with multiple openHAB installs (home/office etc.) sometimes mirror some or all Item states between them, using either an automated rules-based system or a custom binding to communicate the states using MQTT. If you had lots to do, that might be adaptable.
