Why do MQTT topics use complex JSON payloads instead of nested topics/flattened payloads?

[KizzyCode]

I've been wondering why Zigbee2MQTT uses JSON as key-value blobs instead of just using MQTT topics? E.g. why is it zigbee2mqtt/FRIENDLY_NAME/get => {"state": "ON"} instead of zigbee2mqtt/FRIENDLY_NAME/get/state => "ON"?

I've been tinkering with IoT-MQTT pipelines, and seems quite unconventional and a bit overcomplicated/redundant to me; e.g. instead of MQTT topic discovery and pub/sub and string comparison, now I need MQTT topic discovery, pub/sub, JSON parsing, object mapping and property discovery plus string comparison.

I've been thinking about writing a plugin that additionally publishes such a flattened structure under a different topic; but before I do so I wanted to ask why you've decided to opt-in for JSON instead.

[Koenkk]

I think you are looking for the output option

[KizzyCode]

Ok I feel stupid now – don't know how I could miss this —.—
TYVM!