The OP's question is specifically referring to keeping the Device's Last Activity field up to date. As such, as long as the driver issues a sendEvent() call for an existing attribute, even if the value has not changed, the 'Last Activity' will be updated. In this case, we would not want to force 'isStateChange' to true, as that would indeed create an event, which would wake up any Apps that are subscribed to that event. That would result in False triggers of those Apps.
For a device like a Button Controller, things are a little different. In that situation, one must force 'isStateChange' to true in order to allow the same button number to fire the same event multiple times in a row.
Something like a contact sensor must sequence from 'contact: open' to 'contact: closed' to 'contact: open' for events to be fired correctly and to prevent false triggers of apps. Whereas a button controller needs to be able to raise multiple 'pushed: 1' events in a row, as that is a completely valid sequence of events. Thus, the Button Controller drivers need to force isStateChange to true for the system to function properly.
This is correct. I believe all drivers, including Hubitat authored drivers, need to use the platform as it was originally intended. Let the platform decide if status update is worthy of a new event (except when forced to do so via the isStateChange option described above), as this will always result in the Last Activity field being kept up to date.
In general, the real issue is that Hubitat does not yet have a foolproof way of allowing users to know the health of the attached devices. It is not exactly a trivial problem, as many devices are very 'sleepy' in order to same battery life.
