Why were CBC_SHA256 ciphersuites like TLS_RSA_WITH_AES_128_CBC_SHA256 defined?

It is my understanding that:

1. In TLS, the hash function is used only in HMAC construct.


2. SHA-1 is secure when used in HMAC.


3. TLS 1.2 switched the PRF used to derive the symmetric keys to no weaker than SHA-2, regardless of ciphersuite, thus in TLS 1.2 the hash function named in the ciphersuite is used only for HMAC during bulk data transfer.


4. TLS_RSA_WITH_AES_128_CBC_SHA256 seems no more secure than TLS_RSA_WITH_AES_128_CBC_SHA, but has more bandwidth overhead (extra 12 bytes each record, which may be up to 16KB long).

Is the above correct? What was the rationale for defining the CBC SHA-2 ciphersuites in TLS 1.2? Was it a hedge against HMAC_SHA1 getting catastrophically broken but in such a way that leaves HMAC_SHA256 intact?

If my analysis is correct, does it mean that there is no point in supporting TLS_RSA_WITH_AES_128_CBC_SHA256? Is this the reasoning behind Android 5 and golang not supporting CBC_SHA256?

Note: I know about PFS and AEAD, this is a question about the merits of CBC_SHA256 vs. CBC_SHA.