Google's head of network crypto code for both Chrome and the servers wrote in 2010 that the CPU overhead of TLS at Google was 1%.
TLS has not been slow for a very long time. Saying it's slow is almost like saying "I heard that the 8087 is slow so I don't use floating point number in my code". Also, it would take you 1 minute to Google this fact.
SSH has a very different use case than the web. It is for technical users accessing internal systems. It is always deployed in a way that requires authenticating the client to the server and not just the server to the client.
The technology inside modern SSH and modern TLS is the same, equally secure and fast: AES-GCM or ChaCha20-Poly1305 for bulk confidentiality and integrity, RSA or ECDSA or EdDSA digital signatures for authentication, ECDHE over P-256 or X25519 for key exchange and forward secrecy. Modern Intel CPUs do more than 2GB per second per core of AES and a few thousands of RSA handshakes per second. EdDSA is faster than RSA but will only be available for TLS next year.
SSH were quicker with standardizing X25519 and EdDSA, but adoption of newer versions and cipher suites is quicker with TLS, both things for complicated non-technical reasons.
Both protocols allow clients to be authenticated by the server using pre-shared keys or public keys, with the private key potentially being on a smartcard.
Both protocols can use pre-shared keys or trust-on-first-use or PKI. SSH defaults to trust-on-first-use. The Web defaults to distributed cached trust-on-first-use via domain validated webpki certificates. Clients can and often do non-default authentication (e.g. pinned certificates issued by corporate CA).
Since the Snowden revelations, some organizations, most notably Google, have declared war on unencrypted traffic and are pushing everyone to use TLS. Sites that support TLS should default to TLS and maybe not support plaintext. Why doesn't stackexchange.com default to TLS? I don't know.