I believe the reason for not enabling support for TLS1.1 and TLS1.2 in a TLS client by default was widespread TLS version intolerance among the installed TLS servers at the time. As Adam Langely (person in charge of server and client (Chrome and Android) TLS stack in Google, forker of OpenSSL into BoringSSL and author of Go's TLS stack) wrote in 2011:
Despite it being nearly twelve years since the publication of TLS 1.0
[RFC2246], around 3% of HTTPS servers will reject a valid TLS
"ClientHello". These rejections can take the form of immediately
closing the connection or a fatal alert. Intolerance to the
following has been observed:
Advertising version TLS 1.0.
Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1
or 1.2, around 3% for greater than 1.2).
Advertising a version greater than 0x03ff (around 65% of servers)
The presence of any extensions (around 7% of servers)
The presence of specific extensions ("server_name" and
"status_request" intolerance has been observed, although in very
The presence of any advertised compression algorithms
This issue with TLS version intolerance caused browsers to fallback retry, which caused Adam Langely to invent SCSV to protect against downgrade during fallback. TLS 1.3 had issues with proxies and switched the version negotiation mechanism to work differently and left two wasted bytes in the TLS record to say "TLS1.2", fixed forever.
To try to combat ossification and intolerant servers being deployed, Google's David Benjamin introduced GREASE, a system that injects fake never-allocated identifiers into options lists in TLS ClientHello to force TLS servers to correctly implement the required "disregard unknown values proposed by client and continue with the known values" behavior.