This happens when a device loses connectivity and it's not a good thing. It slows throughput...
Thread Partitions allow devices to maintain communication with other devices in the same Thread Partition but not with Thread Devices in other partitions.
Okay, that makes sense.
I learn sooo much every day on this site, there is no way I could afford this as a subscription. 
Periodic polling (during wake intervals) is how Zigbee/Thread battery operated end devices normally receive commands; polling happens frequently enough that the device may appear to be 'always on' (it will accept configuration commands, refresh commands, etc. within a few seconds) but it doesn't remain fully powered all the time. There are also specific poll intervals; a device will temporarily go into 'fast poll mode' to fetch a message if its 'slow' polling interval indicates that it has buffered data waiting, but it is still periodically waking and sleeping. Zigbee design specs recommend wakeup intervals no more frequent than 7.5 seconds (aside from 'fast poll'); obviously locks are different and poll more frequently (they also have big batteries).
According to SiLabs:
In their normal operating state, ZigBee end devices shall poll no more frequently than once every 7.5 seconds except where this specification indicates otherwise for a particular device description, or under the following conditions.
•ZigBee end devices may operate with a higher polling rate during commissioning, network maintenance, alarm states, and for short periods after transmitting a message to allow for acknowledgments and or responses to be received quickly, but they must return to the standard rate indicated previously during normal operation.
•It is recommended that ZigBee end devices poll much less frequently than once per 7.5 seconds, especially when the device normally only communicates due to user interaction. To further clarify, except for one condition in the Simple Metering cluster (refer to DD.3.3), all cluster interactions that read or write attributes, or cause command exchanges should limit transactions to once every 30 seconds.
There's no reason (or any practical way if you're powering the thing with a wafer cell and want it to operate for more than a few weeks) to keep the radio and chip fully powered all the time.
Zigbee SED polling isn't to be confused with how sleepy Z-Wave devices work--that scheme is different; a Z-Wave sleepy device's wakeup time is configurable and can be several hours; if you want to do anything to change a Z-Wave sensor's configuration parameters you either wait for hours or physically 'wake up' the device by hitting its button. It will then wakeup for a certain amount of time (during which you get a shot at sending it configuration data), then go back to sleep for hours again.
I don’t share that view. It is a predominantly local solution.
Market size / volume issues at present
Using multiple controllers in a mesh or using MQTT, logic / scheduling or cloud already creates this scenario.
Ease of use and expansion of the market adoption / sales? I don’t think this will happen
There is no local solution for running scheduled routines on any of the routers, so I consider that cloud based.
I'll bet a new hub on that. LOL!
Have you tried secure pairing in Z-wave? I would have rejoiced if it was only a 20% failure as I was getting my locks and secure devices into Hubitat! And let's not even start about all the work needed to remove the "ghost" devices left behind by Z-wave pairing failures.
So it still appears to me that the video is complaining about imperfect early/first end-device implementations, where we already have and accept greater long-term, nobody is doing much about it (and I'm pointing to silicon labs here), imperfections in how smarthomes already work.
Though this is definitely all in the "the next year will tell" category as devices come out and the true test of interoperability is seen!
(Zigbee, on the other hand, seems to pair right just about every time)
My personal experience was closer to 90% success rate and I only created a ghost once. That was due to a really crazy coincidence (vehicle hit a pole up the road causing a power at the house - hub ran fine on battery. But the switch on the wall did not) while I was trying to include.
There's no internet required for functional Thread usage. Apple Home has no problem working without an internet connection. The only thing that won't work without internet are some Siri commands and control from outside of the house. In fact there's not even a controller/hub required for Thread devices. Probably the oldest consumer implementation of Thread are the Nest Protect smoke detectors. They work great and only require internet for the phone app to work outside of the home.
Thread can communicate outside a local network, but it is not required.
Any internet requirements is based on the device manufacturer's implementation including Matter. Not the radio.
The Apple Home implementation of Matter/Thread is all local (Thread support requires a recent Apple HomePod or AppleTV with a Thread radio.) Just like HomeKit, Apple's implementation is pretty much all local, including the processing for automations, with the exception of voice processing and controlling your home when away (as mentioned by @bill.d above.) Apple is also the one major company that actually puts privacy of its end users' data as a high priority.
Matter and Thread implementation is expensive and will be costly for Hubitat. To integrate this solution, membership would be required. I have signed up as an Academic member of Thread and Associate member of Matter (still waiting, they said they would let me know if I'm worthy 
), in hopes to understand more about them. As those two levels are free, I recommend everyone else do this as well.
The annual Matter membership fee of $20,000 at CSA-IoT is for Participant membership and another $7,500 at Thread Group Membership for an Implementers membership. There are higher (Promoter) and lower (Associate) priced memberships, but I'm not sure of requirements or resource availability for those memberships. This means that all manufactures of Matter and Thread devices will also have to pay licensing fees as well as the Matter fees of $2,500 for the trademark on a product. The certification process is another $500 annual fee for each tested product.
Check out the requirements & application process for a chance to win a 2-year complimentary Thread Group membership (First year at Contributor level, US $15,000 value; second year at Implementer level, US $7,500 value).
[CSA-IoT Membership](Become a Member | The Future of IOT - CSA-IOT)
I believe this is going to push a lot of smaller companies away and limit price point competition, but only time will tell.
Not according to Apple...
Does HomeKit work without an internet connection?
Yes, but you won't have access to Siri, automations, and HomeKit devices that use the cloud.
First, that was not an official Apple Website... So, not actually according to Apple, but rather a writer of a web article.
Second, well of course if your Internet goes down, you will not be able to use anything (Siri, Cloud Devices, and Cloud Automations) that rely on the Internet. I think you've mis-interpreted what that writer of the article was stating.
This is no different than Hubitat and Home Assistant which also have excellent local processing capabilities.
I use all three of these systems, and they all work extremely well without an Internet connection.
As this is a learning process for many of us, please show a link to the official Apple Website where it you found that I'm incorrect and that automations will continue without Internet access.
...and as you mentioned, Home Assistant, like Hubitat does run locally. They implemented Thread and some Matter devices, which they say will be all this year, but I don't own Home Assistant.
I think this sentence should be read as "X, Y and Z that use the cloud", i.e. specific automations that use the cloud won't be available.
According to Verge It seems that participating companies will have the choice as to whether they let a third party app control their products. If Google doesn't allow Amazon or Apple to control Googles devices, you'll have to use Google's app for Nest, Amazon's app for Echo and so on. Having to use all those different apps can become messy. I'm not sure they'd be able to stop Hubitat users from developing controls, but the average person will have to download multiple apps to use their home automation or stick their loyalty with one company. Has anyone heard more about this? It seems defeating for a new 'industry-unifying' standard that is supposed to make it easier for your smart home devices to connect with each other. It seems they all connect to each other, just so they can get to their specific app for complex routines or scenes.
Who isn't concerned when they read...
"But devices may not have access to all their features through that app. For example, at launch, Matter won’t support more advanced features, like energy monitoring in a smart plug or complicated scene control for smart lights. So, if you wanted to set up energy monitoring or have your colored smart bulbs pulsate with the shades of your football team, you would need to use the devices’ app or an app that supports the functionality you want. At least for now."
Hubitat is already part of the matter consortium
This is designed for enterprise, not consumers. My previous company paid double that for some unknown consortium membership they never participated in. It was simply the cost of doing business. What is the license fee to implement on a per unit bases? I believe it is zero.
A better question is what's the cost to implement? For example, hiring and training a single employee is over $200k/year minimum when accounting for benefits. That before you actually do the integration with the platform that uses many other resources (people) to test and release. That is pricey for a small company.
That all said, Hubitat will implement Matter (and Thread for their next hub). They have no choice if they want to remain relevant. The market decided this a while ago.
A parallel question is how much might this save a small company. If a hub maker wants to support homekit, Google Home, Alexa, Lifx, Tuya, Brilliant, etc. etc. etc., it now has to implement multiple different protocols requiring either multiple people who have to be trained, and likely, lots of implementation corner cutting. All these companies and many more have announced they're going to support matter. Sees like a tremendous cost savings opportunity. The real issue now is waiting for all the certifications to start happening so products can be sold (though I've noticed a lot of new certifications on the CSA web site lately: Certified Products Search | IOT - CSA-IOT ) so it looks like its getting close.
I think the smaller companies will be slower to adopt. Existing technologies and market have already proven to be profitable and there will be more of us that have learned through many lessons why its not a good idea to be on the bleeding edge of technology. They will feel the same insecurities many of us implementers are feeling. At most they'll begin training employees, who will build and play with prototypes to gain the experience and confidence that will be needed to be prepared, if the market for this gets the traction many are predicting. They will let the big guys with deep pockets will work out the inconsistencies. Then, after it's been out a few years and the bugs have been worked out, the small companies will begin adopting and offer a stable product. If they don't see the profitability, they'll continue to bide their time. There's no need to hurry when they've already got an available market share that will increase many times over, as the big guys are abandoning for a new the new technology. Many of us should find prices dropping on the current products as well. I don't believe it will ever be "the" industry standard and neither will any other, as there will always be competing entities, but I believe it will have its place among all of the other industry standards.
Props to Rick for one of his previous posts...
Download the Hubitat app
