At the last few connectathons, we've discussed the limitations of how consistently a server can/should alert subscribing clients about changes. Some of that discussion can be viewed on zulip here

In chatting with Grahame, we settled on clarifying the specification a bit more around some of the complexities that prevent this. For example, many people wonder why the spec calls out deletes specifically (some servers may indeed alert about deletes, if they allow them). However, there are likely some complex cases that the spec can use to describe these complexities more accurately. Right now, it just mentioned updates and deletes. However, there are also security complexities (things outside of the server's direct visibility) as well as changes to the subscription itself that can make this especially challenging. EG: If someones privs change, which causes a result to fall out of the data set, alerting the client on that could be a security/privacy issue as well.

This section of the specification could use more clarification as to why there is no guarantee that every update to data may not be able to be sent in a subscription - the delete statement is a concern, but isn't the most complex aspect of this, and is causing some confusion.