I have identified the issue. The fix will be included in the July patches this weekend.
The problem is isolated to XenForo installations running VaultWiki 4.1.0 RC 2 or later. In this version, VaultWiki began allowing XenForo to fully handle storage of the IP address data for its content.
When queuing the notifier task, VaultWiki includes a copy of the content, including joined table data, and hands that copy to the queue (in case the content is altered significantly before all notifications complete). This copy is JSON-encoded. However, XenForo encodes IP address data in a binary format, and binary data is not compatible with JSON, so the task ends up queued without a reference to the trigger content. When the task executes, since no content triggered it, there are no people watching to alert.
This problem is not isolated to edit alerts, but also the last-update column in content lists, certain deleted content, and others. Some of these effects, such as orphaned content, are possible to correct in a future upgrade script; for others, the data is lost (not possible to send out alerts, since the trigger event has passed).