The I2C protocol is a distributed state machine. Each slave node needs to know what bit in the message sequence is being sent, to match it against its own address. As a result, a single missed bit results in a slave not recognizing its own address and going dark -- or, worse but rarer, potentially recognizing its address in the midst of data sent to another slave, and responding inappropriately. Observing this in a real system indicates either a signal integrity issue or a bug, but signal integrity issues do happen, and this non-recoverable behavior is somewhat unique to I2C, and somewhat cursed, turning what would be a transient error into a permanent one. In practice, most I2C devices have some mechanism for recovering (sufficiently long pulse on clock line, so many clock edges all low, a dedicated reset pin); and for the few that don't, forcing a reset of the device through a high-side drive or similar works fine; but the fact that these mechanisms are outside of the protocol, rather than inside it, is also cursed, and means that for an I2C bus of mixed devices there's not guaranteed to be a single method acceptable to all of them.

Yes, but every device is slightly different and sometimes you need obnoxious hacks to even detect that there is a problem at all...