The comment about CouchDB and the "difficulty of getting application-level conflict resolution right" I am not really certain how it applies, You dont have to handle conflicts in Pouch/CouchDB if you dont want to, there is a default model of last write (actually most edits) wins but you can handle them if needed
I've been down the CouchDB/PouchDB path several times with several different engineering teams. Every time we were hopeful and every time we just couldn't get it to work.
As one example, I worked with a small team of engineers to implement CouchDB syncing for the Clue Android and iOS mobile apps a few years back. Some of my experience is written down here[2]. After investing many months of engineering time, including some onsite help from Jan Lehnardt[3] we abandoned this architecture and went with a classic HTTPS/REST API.
Other times and with different teams we've tried variations of Couch including PouchDB with web stack technology including Electron and PWA-ish HTML apps. None of these panned out either. Wish I could give better insights on why--we just can't get it to be reliable, or fast, or find a good way to share data between two users (the collaboration thing is kind of the whole point).
[1]: https://guide.couchdb.org/
[2]: https://medium.com/wandering-cto/mobile-syncing-with-couchba...
I hope this approach avoids most of the pitfalls you mentioned.
Your Git analogy is also spot-on, but I think you don't take it far enough. Creating a repo is cheap, and I believe CouchDB databases are, too (altough I'm still very new at this). You seemed hesitant to create too many.
Good point about notifications, though. I think you'll still have to have a server process that manages that kind of thing (and probably inserts notifications in other users's databases).