If it weren't for Internet infrastructure hobbling SCTP (via firewall), SCTP provides the same QUICC (session multiplexing) within same 5-tuple and with way much lower packet overhead and smaller code base too.

As with any network protocol design, the tradeoff is slighty gained from versatility over loss of privacy. So it depends on your triage of needs: security, privacy, confidentiality.

Now with the latest "quadage", unobservability (plausible deniability).

From what I recall, one downside to SCTP is that things like resuming from different IP addresses and arbitrarily changing the amount of connections per socket didn't work well in standard SCTP. Plus the TLS story isn't as easy. QUIC makes that stuff easier to work with from an application perspective.

Still a fascinating protocol, doomed to be used exclusively as a weird middle layer for websockets and as a carrier protocol for internal telco networks.

Unfortunately most of the existing communication protocols that are standardized conform to a broken model of networking where security is not provided by the network layer.

Cryptography can't be thought of as an optional layer that people might want to turn on. That bad idea shows up in many software systems. It needs to be thought of as a tool to ensure that a behavior is provided reliably. In this case, that the packets are really coming from who you think they are coming from. There is no reason to believe that they are without cryptography. It's not optional; it's required to provide the quality of service that the user is expecting.

DTLS and QUIC both immediately secure the connection. QUIC then goes on to do its stream multiplexing. The important thing is that the connection is secured in (or just above) the network layer. Had OSI (or whoever else) gotten that part right, then all of these protocols, like SCTP, would actually be useful.