Preamble
I’m working on a reply to this post on the IPFS GitHub, and it may have gone in a different direction from the thread (unsure). While I mull over cutting this down (it would be the longest post in the thread by a lot), I figured why not share in our own space? 
Main Thoughts
Nice, totally agree on that point @ianopolous. By the way, @textileio are big fans of cryptree (I think @fission-suite also uses cryptrees).
Sorry for the delayed reply, and thus rolling back to an earlier topic! Yup, we use cryptrees as well. Perhaps some colour on how we’re using OCAP and cryptrees at Fission can help clarify UCANs for this discussion. We have a bunch of constraints that may or may not lead to a useful design for this discussion (for instance, we assume pipes are leaky, must work in a browser with no plugins). Also worth noting that I like the Peergos approach in general 
However, it’s been a while since I’ve looked at Peergos, so please do correct any inaccuracies below!
We use UCANs specifically for accessing mutable resources — i.e. to update the DNSLink/IPNS, with granularly expireable & revocable write keys at the per-user level. Strictly they really belong more at the IPNS layer (or services). Given UCANs, we also can check that the structure of the updated data follows arbitrary rules, and can be used across resources and atomically with multiple resources at once. This does necessitate that whoever is doing the updating checks the UCAN (self-hosted user / desktop daemon, some consortia, a central server, or anything in between.)
(As an aside, most of our users come from web2, and their biggest concern is that read revocation can be expensive, though it hasn’t been a problem in practice at time of writing).
The private portion of WNFS’s write functionality itself is strongly related to the original cryptree, with the addition that upward paths are hidden, and we need fewer keys per directory. There is no requirement to validate a write signature on the outside of an encrypted node, since this is handled once with UCANs, but nothing precludes that from working together with a more Peergos-type signature (though unsure what the implications are for leaking structure?). Our appraoch has the tradeoff that there may be unreachable nodes to when the filesystem structure is rediscovered (which gets scrambled in an MMPT) if a malicious user has write access.
Cryptree + UCAN together address the problem space from this thread, but UCANs in particular are pointed at the more general problem of distributed permissions across many kinds of resources (IPNS, DNS, email, BLS cosigning FileCoin transactions), secure account recovery, granular permissions, multi-resource atomic transactions, and revocation of delegated permissions, while retaining interoperability (federation, delegation) and familiarity for devs coming from a web2 context. Power and generality are inversely correlated, so it’s entirely possible that UCANs are too general, but we’ve found them extremely useful for these use cases.