@chipmc, glad to hear your impressions!
As for the ERROR state, I believe you need to now think about the user experience, whether it’s your own or for a product owner. If the water sensor has failed, ideally the user is made aware of this, either visually (flashing LED with color or blinking codes or a small OLED) or digitally via SMS, email, etc.
Hardware faults, whether temporary (a reset fixes the problem) or permanent (true hardware failure) is one of THE sources of concerns in commercial and industrial systems. Other failure modes include intermittent or unreliable values. All this to say that you need to think about how a sensor/device can fail, what the likelihood of that failure is (MTBF), how you could recover from the failure (power off/power on, reset, etc) and what is feasible for your product. Then, design your hardware and software accordingly. Your board already has some great resiliency protection for the Electron.
In the case of the soil moisture sensor, besides rebooting, your only other option for recovery may be powering the sensor off then on using a MOSFET or other power control device. If that doesn’t work, then put the system in a safe mode (turn off the water) and enunciate the error to the user, perhaps on a daily interval, until the unit is attended to.
I doubt MTBF is available for that moisture sensor so you will need to assume. In the end, if you design the product to be user serviceable then you could offer replacement parts ($$). Or offer a whole-unit swap (again $$). In either case, the user needs to know of the failure.