As well as a more convenient set of interfaces for sending data, SCTP introduces native multihoming support. When you establish a TCP connection, it is uniquely identified by the sending and receiving address and port. With UDP, there is no notion of a connection, but packets are sent between sockets (bound to a port and an IP) and endpoints identified by an IP address and a port. With SCTP, each endpoint can be identified by a set of IP addresses, rather than just one.
This means that you can keep an SCTP connection open even when one network connection fails. If you have an important server, then you may have it connected to two ISPs with different networks. You may have a satellite connection as a backup and a fiber connection for normal use. When a backhoe digs up the fiber, SCTP connections will transparently fail over to using the satellite link. All that the programmer needs to do to support this is bind the local socket to the wildcard address rather than a specific address.
Although you only get the full advantage of SCTP with applications specifically written for it, there are some halfway steps. One of these is a shim layer in the FreeBSD kernel, which transparently maps TCP socket calls to their SCTP equivalents. This allows you to use TCP applications to talk to SCTP applications.
You can, for example, use a TCP-based VoIP client to connect to a remote SCTP-based version from your laptop, advertising your wired, WiFi, and UMTS addresses. When you unplug the wired network, it will transparently fall back to using the WiFi address. Then when you move out of range, it will fail over to the cellular network.
This means that, as long as one user has an SCTP version of the client and the other has an operating system with a shim layer, like FreeBSD, both users get the benefit.