Just to align vocabulary, I guess what you’re calling “System events” here is what I called “Page Notifications” in my first message:
IMO it makes sense with the strategy you propose for the default event types (create/update/delete/addComment) and even the one provided by bundled extension in XS (like and mention, which is actually already enabled by default).
Now I’m not so sure it would be right to enable notifications globally for events provided by a new extension you just installed. Maybe that could be a value to declare when you provide a new event descriptor: to specify what should be its default setting (enabled or not).
My recollection about using an opt-in for the watch was that we were enabling the notifications so that users would discover the feature by having notifications automatically when some activity starts to happen on the wiki. I’m now not sure it’s needed, but we need to remind that currently the only location where you can decide to watch/unwatch a page easily (aka without creating a complicated filter and just by pressing switches) is through the notification area. IMO it’s unlikely users would discover that location by mistake, so I think that if we want to go in the direction you propose we should also provide a better discoverability of that feature. Maybe a way for doing that would be to specify in the page information tab if the page is watched or not, and allow to modify it here too.