Is cipher block chaining (CBC) mode used in SSL encryption? If block reordering is already protected by SSL and TCP sequence numbers, what added advantage does CBC provide?
The sequence number is used to disallow re-ordering of the messages / records themselves, not the blocks inside them. The block cipher / mode of operation is used to keep the data within the messages confidential; the chaining happens over one message, not over all messages - at least not for newer the newer TLS protocols.
Re-ordering of blocks within the messages can be performed if CBC mode is used. However, the plaintext message that is encrypted has been protected with an authentication tag using HMAC, which means that the altered plaintext message will fail verification afterwards.
ECB mode is always insecure if the blocks can have any, interdependent data. The reason for this is that identical plaintext blocks will always result in identical ciphertext blocks, which leaks information. It is similar to using the same IV for CBC mode, but for each and every block. Block ciphers in ECB mode are not CPA secure.
Note that the newer TLS 1.3 protocol disallows CBC mode altogether. There have been many issues with the authenticate-then-encrypt and CBC mode in TLS, requiring protocol specific alterations to CBC padding mode for instance. Nowadays either an authenticated stream or stream cipher mode should be preferred. Most of these modes - such as GCM - use counter (CTR) mode instead of CBC.
CBC is mainly used for legacy applications. It has wide support in crypto libraries, which makes it a logical choice for applications that do not require anything better. Most cryptographers here will however try to avoid CBC mode as it requires a random IV and padding or ciphertext stealing. It only provides real benefits over insecure modes such as ECB.
SSL is an old name. Nowadays TLS should be preferred as SSL may refer to the old protocols which are now commonly disabled in clients / servers. There was some talk about reintroducing the SSL name for TLS 1.3 but fortunately - in my strongly voiced opinion - that didn't happen.