For now, I am not going to use dtoverlay for most of my sensors. This is a decision that I have come to with significant regret. The number of times I get remote IO errors the dtoverlays is significantly higher than other methods available.
For example, a typical BME280 sensor, with python based query of sensor data, I rarely get any type of i2c communication error, even with using Node Red based query of a BME280 sensor, I once in a while get a remote IO error. But with the same sensor, wiring unchanged, on the same Pi device, the dtovelay method for the BME280 sensor I get remote IO errors at least once every few minutes.
Over a 24 hour test, where only the driver/software query method changes I got the following results. Python based, no errors. Node Red based, using the bme280-sensor module, and node-red-contrib-i2c-bus module, 2 errors. However, the BME280 dtoverlay method, over 100 errors. Nor is this behavior limited to the BME280 sensor. I have tried a number of other sensors which dtoverlay supports, and the number of remote IO errors is still more than other available methods as noted above.
The concept of the dtoverlay model, I do believe in, and it has merit. But from a practical sense, at least for now, for the various sensors I have tested, the consistency is to variable for my needs, use cases. Of course, over time I will continue testing, because long term I would love to avoid the code complexity that dtoverlay based methods avoid.
As a side note, there is one other limitation of the dtoverlay design that I would like to see addressed, this is how i2c address conflicts are handled. Let me clarify, this is not an actual i2c address conflict on the i2c bus, but in the /boot/config.txt configuration options parse the explicit specification of i2c address per dtoverlay configuration. For example, the following sensors can have the same hardwired address, due to various breakout board designs, such that HTU21D at 0x40, and Si702X at 0x40 can conflict.
Now of course, when the sensors are wired to the same i2c bus, say bus 1 on Pi4, this is an issue, but that is the not the case I am referencing, the specific issue is that the dtoverlay configuration can't, per my understanding, resolve which sensor is actually present at address 0x40, be it the HTU21D or Si702X is actually present. If you enter the two dtoverlay lines in the the /boot/config.txt file, 1 for each sensor, only the first address match is honored, regardless which sensor is actually present. Meaning if that if you have 2 lines both explicitly qualifying address 0x40, only the first one is honored, acted upon. The dtoverlay logic should be a bit smarter in matching the right driver to the right device, and not relay on i2c address alone. If there is a way to avoid this issue, please communicate it accordingly.