I do have other flows where I use the "simpler" switch, change etc. nodes. But I have found that albeit being super simple in the beginning, they quickly become bottle necks.
So I decided to try to do as much as possible with functions. This has the added benefit of being able to learn much more and perform more complex tasks in the future 
The debug nodes are actually not my real output. They are really just for debugging right now. The output will later be an mqtt out node.
So in the current stage of my little project, I am separating the data for processing.
This will be followed by a block of functions that will process the data.
Once processed, the different streams will be re-joined to form one output message (per device... see more on that in my response to Colin)
Perfectly valid points
Maybe I need to elaborate a bit more.
Device types are different hardware types (usually linked to different manufacturers).
So I have:
- Shelly 1PM, Shelly 2.5 and Shelly 3EM.
- Gosund SP1 and Gosund SP112.
- Refoss P11
- Xiaomi Mijia Thermometer & Hygrometer
- eq3 Thermostat (heating valve)
Devices are then "one piece of hardware" no matter who the manufacturer. Entities are then e.g. power sensor, energy total sensor, power switch etc.
The first three device types are running with tasmota firmware. So they will all have the respective device_id in the topic, e.g. "tele/tasmota_12345678" which is based on the MAC of the devices.
These run to the bottom flow because they are all power sensors and their messages are all very similar.
So the first function checks if it is one of these device types. Since the topic contains the device id, I do not need to split into devices anymore. The second function then splits into the entities Energy Power, Energy Total and Energy Today.
However, those with multiple outputs (e.g. Shelly 2.5 or Shelly 3EM) will need separate processing of these 3 outputs, hence then another function splitting into the entities Power[0] to Power[3].
The Xiaomi and eq3 are in fact bluetooth devices with their own firmware (whose behavior I cannot really influence). They are relayed through an ESP32 dev kit board running tasmota.
So the data comes in via bluetooth to the ESP32 and the ESP32 then relays/publishes the data as MQTT messages via Wifi.
Each Xiaomi device uses "ATC" + a unique ID based on MAC to identify itself to tasmota.
Tasmota does not use the same topic as it does for the Shelly/Gosund device types. This alternative topic is not device specific but device type specific. Meaning, all Xiaomi Mijia devices' data are published via one large message with just one topic (they may be split into multiple messages if there are more than 4 Xiaomi devices).
So I need the top flow to check the message for "ATC" and not the topic.
The same applies to the eq3 valves, which I have not implemented yet because they are not used in summer (and are essentially clone nodes of the ATC flow).
Maybe as an additional note:
I could of course join different functions into one and have less processing steps. But right now this makes it easier to work out mistakes and to follow the processing.
IF this leads to performance problems later, I will merge them into fewer but larger functions.
Until then I think it is easier for you to support and me to learn if I keep each step in a separate node.
P.S.:
Of course I am happy to share the final glow later. It is currently in a private github repo but once I have a more refined and more feature rich flow, I will happily share it with whoever is interested.
