I think the biggest obstacle is the lack of convenient way of nocoiners to get their first coins. I know Haveno, Bisq, etc. have made it so much easier to exchange fiat with the digital cash, but they require participants to already hold some coins as security deposit. Maybe that barrier is what keeps those P2P markets more civilised, nonetheless in the current state nocoiners have to face the chicken-and-egg problem of having to hold coins in order to get more coins.

Other problems remain, e.g. people wouldn't like coin outputs to be frozen for 20 minutes from receiving, wallet syncing is kinda cumbersome, keeping the secret key can be scary for people who are used to traditional services, etc. But people won't experience these issues at all if they can't get some coins in the first place.

Honestly, odds are not so great on Monero: even if all above problems are solved and Monero becomes the easiest way to store and exchange value, that won't guarantee everyone will start to use Monero. Signal is the most convenient way to communicate with close contacts, yet so few use it due to the network effect of the outdated instant messaging apps.

However as the saying goes, the only thing that will ensure defeat is to stop fighting for it. If we want to make Monero mainstream, what we can and should do is clear: make it more useful, and teach more people about the private digital currency. This forum is doing a great job of providing a new way to earn and spend Monero. Maybe you can also take a part, by accepting Monero in your business. Or by catching bugs and building features on Monero software. Or by writing high-quality videos on YouTube that introduce people to Monero. Any challengers?

Nice work, I was also thinking about integrating Monero in Nostr recently. Your protocol document also looks very interesting, though I needed a translation since it's only in German. Here's my feedback:

General

I think you're assuming Watchers to be big centralised services that run on their own internet domains (probably alongside their own Nostr relay infrastructure).
I'm not against lightweight wallet service itself, but the specification should leave out some room for individual users to be able to become self-custodial.

In my opinion, watcher should be able to run on any computer that is always online; ideally, even smartphones could become a watcher and sync the wallet periodically (e.g. every 1 hour) and watch for tips. This way users can avoid giving out private view keys to big watcher providers with minimal friction.

Payment-Info (kind 10037)

• Again, the watcher tag expects its own internet domain as the first argument. Your 'Watcher HTTP API' section implies all watchers must expose an HTTP server. This is just too big of a burden. The HTTP API can be replaced with encrypted messages on Nostr, if such an interaction is absolutely required.
• Why not have ["watcher", "<watcher-hex-pubkey>", "<optional-relay>"]? This way, if relay is not specified, it would imply payer can send tip intent events to any inbox relay of the tip recipient.
• Maybe the watcher tag itself can be optional, in this case it would mean the tip recipient can watch and sign payment receipts using her own pubkey.

Tip-Intent (kind 9738)

• Payer unilaterally deciding the payment ID looks fine, although I concern some security implications. I once thought payment IDs could be derived in somewhat more deterministically random process, something like HMAC-SHA256("<payer-pubkey>", "<recipient-pubkey>:<note-id>:<nonce>"), but I don't think it is worth complicating the specification. Simply mentioning clients should generate payment IDs using a secure pseudorandom algorithm would be sufficient.
• The current way has some advantages over alternatives, e.g. asking recipient to generate a subaddress or payment ID; other methods would require the process to go through more steps (payer publishes tip intent → recipient gives an address → payer pays XMR (outside Nostr) → recipient or watcher confirms receipt), which means more problems (How do recipients manage subaddresses? Should the address be sent encrypted to payer? etc.). So I'm okay with keeping with the current proposal.

Tip-Receipt (kind 9739)

• I also think not containing txid in the receipt is the way to go. This does place some trust on the watcher, and there is some hypothetical issue of watchers manipulating fake tip receipts. But such dishonesty can be discovered by other means, and it is also discouraged by social incentives (it hurts watcher's reputation, whether or not it's a big central service or just a recipient running her own watcher).
• It also appears on Tip-Intent event, but I don't know what the type tag is for. Maybe omission can be the default, and the tag can be optionally set to indicate other modes of payment?

Sorry for being a bit harsh (maybe too toxic), but that is what went through my mind when reading the proposal. Further criticism and discussion are welcome :)