TLS should be, at least in a broad and theoretical sense, a transport layer protocol. But TLS provide authentication through X.509 certificates which are based on a hostname, server name, or whatever kind of "name" that should only exist at application level (Unless we only authenticate ip addresses). So in practice TLS span largely between the application and transport layer. Now I was wondering, are there technical and practical reasons why TLS was not designed to simply provide key exchange methods, and the establishment of a encrypted statefull channel leaving certificates verification to the application layer, creating a smoother transport layer protocol with a more linear interface?
Transport layer protocols like UDP, TCP, SCTP ... are traditionally implemented at the operating system kernel. While it would probably be possible to design a protocol which does encryption at the transport layer (or network layer like IPSec), adoption of the protocol would thus require changes to all relevant OS. This means adoption of the protocol would probably be very slow.
At the time SSL was invented Netscape not only created the major browser but also major server software. It was thus much easier and faster to add the protected transport directly into the application software (both client and server) instead of trying to get a maybe more academically clean approach into the various OS.
Apart from that OSI model and TCP/IP model are just abstract views to how networking worked at the time these models were created. While at this time the complexity was largely at the lower layers, the complexity today is at the higher layers and the OSI and TCP/IP model do not address today's complexity any more. Just take QUIC, HTTP/2 or even WebSockets which implement transport layer tasks inside the application layer.