WiFi you have all kinds of underlying network issues to setup that do not happen or you do not have to account for like WiFi, things like IP Address, Routing, vLAN's, Firewalls, Ports, etc
None of that is a problem for Zigbee.
>>I'm designing a custom automation system for the ventilation in my house and I failed to discover any reason to use Zigbee
Then you are not looking very hard or do not value Dependability and security.
Matter will likely absorb both Zigbee and WiFi anyway as Google, Amazon, and Apple are all backing Matter
My home Zigbee and Z-Wave networks have never come as close in reliability or versatility as my home IP network. I can always put in money incrementally to increase bandwidth or lower latency because the commercial off-the-shelf world for IP is so big — I can do point-to-point microwave links or send my IP network over 120V. And I know for sure, IP networks will never ever be deprecated.
I have some stage lights (just for fun - home light shows) — they speak DMX and not IP, but I just encapsulate DMX over IP and bam, a data connection anywhere in the house without extra data lines. I can send video over IP or make up my own protocol and my IP network can handle it no problem (though maybe with some upgrades if I were to send a lot of video).
Zigbee will probably be absorbed/obsolete on the long run, but Matter is an application layer that runs on both Wi-Fi and Thread.
Zigbee which I'm a huge supporter of, offers this out the box and setting up is as easy as 10 seconds of pairing.
I don't want to spend more time than I need to automating my home or making it a full time job.
And customers want cloud control, it seems, and don't seem to care about the security and privacy issues around it. So why build two separate devices (the smart device + the hub) when you can just build a single device (the smart device) and put the WiFi directly in it? Sure, there might be a cost difference in the case where the customers might have many smart devices (many cheap Zigbee devices + one "expensive" hub vs. many "expensive" WiFi devices), but I'm not convinced the cost is all that different overall.
The main issue I do see is power consumption. It's much easier to make a battery-powered Zigbee (or Z-Wave) device where the customer won't have to change the batteries every few months. WiFi is a power hog compared to Zigbee/Z-Wave, even if you assume that the device (or at least its radio) will sleep a significant part of the time. But many of these smart devices end up being hard-wired, so often it isn't that big a deal. (To be fair, though, I have a WiFi battery-powered smart/keypad lock in a rental property, and its batteries last 9-12 months, so even the power consumption issue is often not much of an issue!)
Beyond that, if a company is going to put WiFi in their device, most of the more "mainstream" vendors are going to have it connect directly to their cloud service, and not bother with local control, except possibly as a fallback when internet access is down. That fallback is nice, when implemented, but for those of us who don't trust these vendors to secure their backends, the "cloud service by default" attitude is a liability. At least with Zigbee/Z-Wave, I know that it's local-only-by-default.
So to summarize: WiFi gives a better UX for customers, and is probably cheaper, too.
Personally I buy only Z-Wave kit for the smart devices in our primary home, connected to my custom-built hub, and don't allow a third-party to manage (and probably screw up) the cloud control bits. It's definitely more work to manage, and troubleshoot when there are issues. Certainly not suitable for your average homeowner.
The 10x difference in power can be papered away by running the radio 1/10th the frequency. Ex: instead of updating every minute (Zigbee), you can update every 10-minutes (WiFi).
--------
I think a lot of these WiFi internet-of-things are fine with the ~15 minute update routine to minimize the use of the (relatively power heavy) 100mA+ WiFi radio.
Zigbee is simpler, but not so simple that you can program it yourself. It is found in cheaper $5 microcontrollers with less oomph than the ESP32... and those microcontrollers also use less power since its just innately a slower protocol. Though... I guess ESP32 is also $5 so cost really isn't a factor anymore.
-------
The absolute limit of 10mA vs 100mA is also pretty interesting.
10mA is just barely what is reasonable to push out of a CR2032 coin cell battery. 40-ohms internal resistance at 3V, so 10mA is a .4V drop... which can be solved with enough capacitors to buffer up the current. A lot of these devices still work at 2.3V or so (-.3 volts from age, -.4 volts from internal resistance), so you have enough headroom for an IoT Zigbee radio with CR2032 coin cells.
You ain't getting 100mA out of a coin cell battery (lol 4V drop on a 3V cell), unless you're also adding a super-capacitor to the circuit or other rather significant forms of power-storage. Then again, 100mA is more than reasonable out of Li-ion / AA NiMH / etc. etc. So ESP32 is still a battery-operated device... just a larger one than any Zigbee solution.
Mind you, the CR2032 coin cell is designed to average ~0.4 mA or less. So you really need to keep the radio "sleeping" most of the time. 10mA is really close to the "temporary burst" limits of the cell, and you're already suffering from significant degradation of the cell's lifespan by running it at 10mA, even temporarily. But the fact that Zigbee "fits" inside of this means that you can design devices around CR2032 cells, rather than AA or Li-ion packs.
-------
EDIT: The setup/teardown speed of Zigbee is also much faster. IIRC, you can connect, send data, and disconnect in ~30 milliseconds on Zigbee. But it requires seconds on WiFi (find an Access Point. Call Access Point. Setup negotiations, etc. etc. 3-way TCP handshake: Syn, Syn-ack, Ack. And then HTTP finally begins...).
A 470uF capacitor can power 5mA across a .4V drop for 36 milliseconds. (I = C * dv/dt). Assuming half the power comes from CR2032 + the other half the power from the capacitor (that's not how electronics work but I'm doing quickie napkin math), that's 5mA from the CR2032 + 5mA from the capacitor. So the 470uF capacitor gives you the headroom to run other parts (sensors / uC, etc. etc.) within the 10mA limits of the CR2032 cell.
Good luck getting a capacitor to do that kind of work across the ~5 seconds needed to setup / teardown a WiFi connection.
Since "Energy" == "Power * Time", the 100x time to connect + 10x power leads to ~1000x energy usage in practice, for WiFi vs Zigbee.
It makes me wonder why far more powerful devices (iPhone, MacBook) take so long to connect to or change WiFi networks.
iPhones / MacBooks don't care about battery life, or connecting/disconnecting from WiFi all the time. Optimizing from 5s connection to 1s connection is completely irrelevant. Its not like people normally disconnect/reconnect to WiFi. The few times I do it (ie: walk into my house / WiFi is back in range), my phone reconnects long before I even take it out of my pocket. Once connected, it stays connected and active.
ESP32 however, is an IoT chip. Optimizing from 5s to 1s connection time is a reduction of 80% of your power usage in practice. Because almost every IoT device will immediately sleep after the WiFi message is sent.
That is impressive though. Good on them for making this process more efficient. It'd never beat a specially designed protocol like Zigbee (or any of the 802.15.4 stuff). But so many people use 802.11 / WiFi these days that these kinds of optimizations are hugely relevant.
You don't feel it because you've spent the time to make it work. But the average person from the street's wifi sucks hard.
My wifi is great already, but I decided to try some of the Ring lighting products. They use Zigbee/Sidewalk which is supposed to be perfect for this kind of use case. Guess what? It isn't. Now I just have a second wireless network to troubleshoot.
At no point does having a second wireless network just for my IOT devices become less work than using the wifi I already have. And if I improve my wifi coverage for IOT, I improved it for everything else at my house too.
>>Sidewalk
Is terrible.
>>Ring
Ring is probably the worst HA brand out there, sorry your experience with Zigbee was bad because you choose a poor implementation of it.
Hell I have zigbee devices I bought of Ebay from failed companies that work better than Ring products.