Is this slowness intrinsic to SCTP, or a matter of implementation?

It's always a matter of implementation.

SCTP is the solution to the problem that Multipath TCP is trying to solve. The biggest challenge is the penetration of TCP libraries vs. SCTP libraries.

...and that SCTP has higher overhead/complexity. But 'slowness' is an imprecise term.

Some applications will perform much faster over TCP because the link is short, reliable, and the application only needs to stream data in-line. Heck, even with network loss you can see gains in TCP vs SCTP.

Some applications will be faster with SCTP because of either the nature of how the application handles network data, or the properties of the network they're traveling over. But speed was never a design consideration of SCTP.

If you want speed, use UDP. If you want something that's fast and "just works", use TCP, or this multipath TCP thing. If you want something designed to pass multiple independent unidirectional data messages across a single "connection" that can span multiple network paths and never miss a beat, use SCTP.

Wasn't sure if there was something particular about SCTP that could induce algorithmic latency such as a buffering requirement, setup/negotiation, congestion control, other overhead, etc.

It uses CRC32 as a checksum and that cannot be offloaded to most commercial NICs. This will also have an impact on routers that manipulate the transport layer ports due to checksum recalculation cost (which is trivial for the checksum used in UDP and TCP)

Routers almost NEVER manipulate the transport unless they are doing something very un-Layer3 like NAT or some other encapsulation.