Most cryptographically protected protocols use TLS these days. This applies to mail protocols, HTTP and many others. The newly designed QUIC has also adopted TLS as its cryptography layer.

However, SSH is different: it has its own cryptography layer.

Why does SSH have a non-TLS cryptography layer? Are there any benefits for SSH to have its own cryptography layer?

About the only difference between SSH and other protocols is that SSH frequently sends messages having just one keystroke. Is the SSH cryptography layer more optimal in the case of extremely short messages?

Related although not the same: How does TLS differ from SSH from a strictly cryptographic perspective?

I think the certificate verification mechanism of SSH (automatically learning) could be supported with TLS. You just wouldn't have a root CA; you would accept each certificate separately and remember the acceptance.

SSH not using TLS is mostly historical; see for instance this answer (on security.SE). In practice, one could perfectly define a sort-of SSH that would use TLS for the data transport part; but, of course, it would not be compatible with existing SSH servers and clients. From a pure cryptographic point of view, SSH actually has some shortcomings with its encrypt-and-MAC encryption, and encrypted "length" field; this does not lead to really exploitable vulnerabilities due to the specific usage of SSH (attackers don't get to trigger thousands of new silent connections with partially chosen data, contrary to TLS, where such things can be done thanks to the magic of JavaScript), and recent AEAD integration mostly fixes them anyway.