Most of the time, simply switching the driver is enough. However, with Zigbee drivers this is not always sufficient, because configuration happens when the device is first added. Until the driver has been tested exactly the same way a user would experience it - taking a brand-new device out of the box and adding it for the first time - we cannot rule out potential issues.
It is also recommended to reset the device itself first. Some devices retain their previous configuration, which can make later debugging much more difficult.
When developing drivers, I go through this entire procedure (remove device → install driver → reset device → add device) countless times. Only once everything works perfectly do I test what happens when you simply switch the driver.
With Matter this is usually irrelevant anyway, since the drivers are structured quite differently. With Zigbee, however, things are not that straightforward.
Our goal is to rule out any esoteric errors first - especially when I don’t even have the device, like in this case. Often times we develop drivers blindly, without the hardware and therefore the logs.
By the way: for a long time it wasn’t even possible to simply switch drivers in the app.
This device is a great example. Looks very basic, but the driver is complex. Only in the final version it’s possible to switch the driver, because an external tester confirmed that it keeps its configuration. We can write the configuration at every life cycle, but the question is if it makes sense. Is it really a good idea to change the power on behavior of such a device? What is the default after a factory reset? What if we can’t read back the attribute of a weird manufacturer cluster (see the sections about the Robust Zigbee handling and the Silent / partial responses). What does the user expect?