> If you send, they need to trust you, if you receive, you need to trust their mint
I think you misidentified where the trust assumptions enter in. It's not related to whether the button you pressed is the Send button or the Receive button, what matters is whose mint holds the money. If your own mint holds all of the money, you don't need to trust anyone, regardless of whether the button pressed is "send" or "receive." I think it gets interesting when each counterparty holds their own money, and interactions happen via atomic swaps.
You might say this is "essentially no better than if you used lightning," but if you think that's a put down I disagree. Lightning is very powerful but hard to work with, partly because different backends have different APIs. Cashu unifies everything: regardless of what backend it runs on, it bolts a unified scripting interface on top, and thanks to this interface, I think it's easier for coders to programmatically authorize payments from a user's node, process refunds in the event of a protocol failure, and perform swaps.
Also, it's very useful for prototyping. Perhaps some of the things I mentioned can't be done on cashu without introducing trust assumptions. But since cashu's scripting language is similar to bitcoin script, that means if you can build a prototype on cashu, then even if it's partially or fully custodial in that environment, you can then copy the design directly into bitcoin script and make a self-custodial version. After that, it's probably wise to lift it onto layer two, but cashu gives you a taste of that in the meantime, which is very meaningful for early adopters, testers, and scientifically minded folks.