With UDP, TCP and SCTP, if you need to change ports in the header, then you need to update the checksum. The traditional TCP/UDP checksum is kinda crap, but this works in its favour here, because you can just perform a corresponding and easy adjustment of the header.
SCTP protects packets with a strong CRC32C checksum. This is on the whole a good thing, but you can't do the twiddle trick with CRC32C. If you're rewriting ports, you need to recalculate the checksum over the entire packet.
This means that linerate SCTP NAT accelerators have never existed. On the whole, what SCTP NATs exist only do address translation: If two people try to establish outbound SCTP connections from the same source port, the second person's connection just gets dropped by the NAT.
It's still there but there hasn't been a need for a protocol to really use it. Protocols like HTTP(S) could really use the SCTP benefits but those need solid client implementations; server protocols like DNS or FTP are restricted more by their own limitations than by TCP, really. Of course you'll find niche use cases where SCTP would've been a godsend, but without proper Windows support _and_ broken middleboxes ruining everybody's internet experience, SCTP was sort of doomed from the start.
MPTCP has some compatibility advantages and TCP-inside-TCP allows for solid client side implementations that can be linked to the userland code itself (https://github.com/ngi-mptcp/curl/wiki/Multipath-TCP-on-Wind...) without elevating credentials; sadly, SCTP didn't have that luxury, as Windows (rightfully) restricted access to raw sockets not long after SCTP began to gain popularity among its fringe group of supporters.