It's good for most use cases for it to be a black box. TLS apis that were designed in the 90s still work with the newest protocols and ciphers and bug fixes. Consumers of the library can blindly and transparently adopt 30 years of research into the topic.
TLS APIs with moving cryptography targets have proven quite useful. I'm only sad that more low-level cryptography never got popular. In a perfect world, you tell the OS what key/trust store to use, what domain to connect to, and you just get a plaintext socket that'll do all the cryptography for you, regardless of whether you're using TLS 1.0 or TLS 1.3.
I know the layered network protocol design is flawed, but I really like the elegance of the old design where TLS/IPSec/DTLS/WireGuard is just an option you pass to connect() rather than a library you need to pull in and maintain. Windows has something like that and it feels like somewhat of a missed opportunity for the internet.
TLS 1.0 and TLS 1.1 are both a bad idea. If the far end of the connection isn't on a trip out of the solar system or buried under the ocean it needs to be upgraded. TLS 1.0 is from last century.
That's not the point. The point is that the application could've been written when TLS 1.0 was state of the art and now works over TLS 1.3 by simply updating the operating system. The OS can pick a safe set of communication protocols for you (unless manually override by user config to make broken old TLS 1.0 connections still work).
connect(2) and these other kernel mode interfaces are definitely the wrong layer. Should be done in user mode. You also want to be able to replace the transport layer with whatever you want.
I think an opaque layer that lets you poke at internals when you decide you know what you're doing is the way to go. Eg. About 10 years ago I implemented certificate pinning atop a 1990s Microsoft API... you can use the api the "dumb" way and not touch it, and then optionally you can easily switch to implementing features the API vendor never envisioned.
You don't really need NIC TLS unless your bitrate is rather high and you're serving data that is stored on disk / in disk cache rather than data that was just generated on the CPU.
Bulk ciphering is pretty inexpensive since Intel Haswell (2014) where there was a big improvement in AES-NI, but the load and store around ciphering static content that could otherwise avoid a trip through the CPU can be a significant bottleneck at 100gbps+. I'm sure there are measurable gains from TLS offload in other situations, but it's only critical for static content at high bit rates.