Disco should really shine with embedded devices, and there it should make sense to use keccak-f[400] instead of keccak-f[1600] (which we currently use).
The Strobe version also doesn't include what permutation is used, I think it should be but my suggestions on the list didn't go too far.
After some discussions with various people, it seems like there are two things that make Disco not so great:
for embedded devices, the 1600-bit state is too big. keccak-f[400] is better but it's not a standard. In this regard, writing an RFC for keccak-f[400] sounds like a good project
for more powerful devices, keccak is (usually) not hardware accelerated and thus not that performant compared to AES-GCM. In that sense Noise makes more sense. BUT, we haven't experimented with 12-round keccak (like kangarootwelve).
Disco should really shine with embedded devices, and there it should make sense to use keccak-f[400] instead of keccak-f[1600] (which we currently use).
The Strobe version also doesn't include what permutation is used, I think it should be but my suggestions on the list didn't go too far.