First, MySensors is not really a mesh. It's a star/tree topology.
Zigbee can use star/tree/mesh, depending on choice of manufacturer. As usual, there pros&cons in these different modes.

To get a better picture, you would need to check what looks IEEE 15.4 etc specs, MAC, app and others zigbee layers. Then compare with MySensors layers.
Saying this because tekka and I took a look.

To be transparent, MySensors is great, but less "advanced" (less time and resources than pro stacks). It has fewer modes. It's a tree network with non-beacon mode only, no (random or not) frequency hopping feature yet.
Which means it's based on sleeping nodes (pros&cons). One inconvenient for example could be no control during sleep mode, no sync, repeater weak link etc. The advantages is less power consumption and resources needed.
Note: less power consumption is just about few uA differences..

I can't explain everything, better read if you're curious
I read about it, to know what could be improved. Changes can imply hw and sw.

Regarding your hardware links, I think your first link (4euro) is not a zigbee module. It's a hc05 bluetooth module, with a pcb footprint which is compatible with some zigbee modules.

Yes. As a relative beginner I don't even understand how Zigbee can run on it. Doesn't the NRF24 have it's own unique lower level stack? Or do their protocols use the same modulation? It's curious.

I am trying to build a controller that is as small as possible, in order for it to fit inside a fake LED candle. It would rock if the NRF24 that it uses for MySensors could somehow also do Zigbee at the same time. Sharing the radio. Would that even be possible? Or does MySensors 'hog' it?

Zigbee is an open standard (and since recently so is Z-wave), so in theory implementaton should be do-able..

I have a similar question : "Mysensors vs Bluetooth BLE".
More specifically, what was the point to develop the mysensor protocol when BLE is available with very low cost modules (which is not the case for zigbee in general much more expansive) ?

Is it that BLE is constrained to remain on 2.4 GHz when mysensors protocol can run on many frequencies kind of transmitters ?
Is it that mysensors can be even cheeper ?
As far as i have understood a similiratity is that both are not IP based nor mesh protocols.
....
BLE is a much more complex protocol up to the application layer however the success of mysensors in the DiY community seems to imply that much of the extra offered capabilities by BLE (security?, complete endpoint identification to the network?, network management capabilities? ) are of little value for most domotics applications ...(?)

Or may be it's just that BLE is not designed to allow the BLE nodes to declare themselves to controllers such as domoticZ , ...

It would rock if the NRF24 that it uses for MySensors could somehow also do Zigbee at the same time. Sharing the radio. Would that even be possible? Or does MySensors 'hog' it?

Zigbee is an open standard (and since recently so is Z-wave), so in theory implementaton should be do-able..

Yes it would, but I don't think you'll see it soon (>months), and not with nrf24..
Like I said previously, this imply "some" hardware and software changes, not very backward compatible, so that's not a very top feature in todo (the native zigbee/mysensors bridge) even if we already talked about this for fun There are others things to improve imho..

More specifically, what was the point to develop the mysensor protocol when BLE is available with very low cost modules (which is not the case for zigbee in general much more expansive) ?

I don't know exactly about MySensors roots (I wasn't there), but it's good to remember that MySensors focus always been on simple hardware in arduino for beginners like 328p, nrf24 etc. so far.
And you can't run BLE stack on all kind of hardware. BLE for example has a heavier footprint than MySensors (and zigbee too) and needs more resources.

Is it that BLE is constrained to remain on 2.4 GHz when mysensors protocol can run on many frequencies kind of transmitters ?

Yes, even if at the beginning MySensors was 2.4ghz only. Lot of people use it for sub-Ghz (433,868 etc).

Is it that mysensors can be even cheeper ?

This depends on your project.

As far as i have understood a similiratity is that both are not IP based nor mesh protocols.
BLE is a much more complex protocol up to the application layer however the success of mysensors in the DiY community seems to imply that much of the extra offered capabilities by BLE (security?, complete endpoint identification to the network?, network management capabilities? ) are of little value for most domotics applications ...(?)

Yes BLE stack is more complex. And in some case you can run less nodes in a network than MySensors. That depends on implementation, manufacturers etc.

MySensors can be as secured and more.. Imho, regarding security, I like the idea to use proprietary protocol, for example in 2.4ghz like MySensors, than BLE which is compatible with phones. I prefer to use a gw..Especially for HA, as in general, we use advanced controllers. Of course, it depends on your project and needs.

You can easily access to the MySensors stack to make any change..
For example, easy to say this stack or this one is now open source, less fun when you have to dig in sources always the question of is it worth it? why? as a dev do we really need it, or is it just for challenge but waste of time as there could be others priorities? what are the compromises, pros&cons etc.

Or may be it's just that BLE is not designed to allow the BLE nodes to declare themselves to controllers such as domoticZ , ...

That depends on the controller used, sometimes you're limited to a type/brand of devices. You can also tinker with nodered as proxy.

Finally:

if using zigbee or BLE, what would you miss?

if using MySensors, what would you miss?

and if the point is just about some sort of universal compatibility, to have possibility to buy cheaper hw, then is ROI worth the effort? Couldn't it be solved with nodered? etc

@alowhum Zigbee being "a standard" is not an advantage at all. As you put it, it is indeed not true at all. Using "a standard" in the meaning of "a formal definition of one of the piece of your puzzle" is only an advantage when you want to potentially replace that piece by a piece produced by another manufacturer and still get that talking to the rest of the puzzle.

You should also consider that there are two kind of standards : "committee" standards, where experts provide a formal document and people pay to adopt that way of doing things, and "de facto" standard, where there are enough users that do things the same way (or buy the same thing) that it guarantees sufficient resiliency. For example, USB is a committee standard (but if you use A, micro, mini etc. you have to adapt), Arduino Uno is a de facto standard (and there as well, you can choose between Uno or micro, etc.), and its success made possible the clones costing a few bucks.