Https es un protocolo. Eso significa que ambas partes tienen que estar de acuerdo en ello. Incluso solo esto haría las cosas un poco raras: ¿qué haría el navegador, intentar conectarse a través de https, luego, si eso falla, volver a http y guardar en caché esa decisión por un período de tiempo? Si algo cambia en su sitio, ¿cómo lo comunica al navegador para que se actualice su caché? Aquí hay una serie de aspectos prácticos que deberían resolverse para que esto ocurra en el mundo real, y aún no lo han hecho.
Más allá de eso, no todos los sitios que aceptan una conexión https realmente funcionan a través de https. Como un simple ejemplo, el sitio web del New York Times escucha en el puerto 443, pero si cambia la URL para que un artículo sea https, simplemente lo redirigirá nuevamente. Si el navegador hiciera su propia redirección de https automáticamente, esto podría ponerlo en un bucle de redirección infinito; como mínimo, estaría esperando a través de dos solicitudes http para cada página en lugar de solo una.
Por lo general, hay más trabajo por hacer para hacer que un sitio web esté disponible para https que simplemente configurar un terminador de https (aunque incluso eso puede ser un poco de trabajo, ya que necesita realizar una prueba de carga para asegurarse de que puede manejar todo su tráfico - Una vez, rompí un sitio web previamente escalable que se saltaba este paso. ). Uno de los problemas más importantes es asegurarse de que todo el contenido que incruste en una página también se solicite a través de https, o de lo contrario obtendrá advertencias de contenido mixto, y el usuario solo verá una página rota. Esto puede ser particularmente molesto si tiene contenido generado por el usuario, porque ahora tiene que hacer un poco de base de datos para arreglar las cosas que han estado agregando, y tenga mucho cuidado de asegurarse de no arruinar algo mientras haciendo eso. Y ahora tiene que usar https en su CDN, y algunos aún no lo admiten tan fácilmente, o quizás tenga que actualizar su plan para poder usar un certificado personalizado (ya que tenía un CNAME de su dominio a su servidores). Y ahora eso rompe algunos scripts que tienes, porque están escritos en Python 2.6, y eso no es compatible con SNI.
La lista continúa. El punto es que, en realidad, hay una cantidad no insignificante de trabajo para que muchos sitios web realicen una transición completa a https, y si un navegador intenta forzarlos todo al mismo tiempo, es casi seguro que haya cosas rotas. Y eso apesta para los usuarios.