I think the biggest “challenge” with these protocols is that they’re generally far far heavier in technical requirements - from a hardware/protocol-stack/processing perspective - than the typical UPnP implementation. Which is fine for the Professional Audio industry, but not so much for consumer home use.
And thats in addition to a dearth of consumer Use-cases. As @mwilson suggests, open multi-room streaming is perhaps a more obvious use-case, but very low-cost proprietary implementations from Sonos, Roon etc. already exists, not to mention bridging the gap through server software like most UPnP Servers can. Most other use-cases, like multi-channel routing/monitoring/mixing etc. is really only for the Professional industry, not so much consumers, so the impetus to implement this for consumers just isn’t there.
Besides, many consumers have enough problems just getting basic stuff like Mosaic/device discovery, or Roon, or DSD streaming, or even Playlists to work properly, imagine if IEEE 1588-2008 (PTPv2) requirements were thrown into the mix!!? dCS would need to go hire a couple of CCIEs to man support desks 24/7
That said, I’d imagine that if someone like StreamUnlimited eventually adopts one of these into their hardware/software stack, then we might see broader adoption among high-end audio manufacturers.
On that basis, I think IEEE AVB has a much greater chance of wider adoption as there are already open-source Linux/ARM based implementations which could be relatively easily incorporated into something like StreamUnlimited’s S800 boards. Plus, Apple’s MacOS already has built-in native AVB support!