As adev_ mentioned, TLS implicitly requires a lot of things that can be considered expensive for very low power devices (dare I say "bloat"). Examples being things like X509 certificates.

Another thing to consider is that TLS supports multiple use cases and has multiple versions, so it has stuff like algorithm negotiation, version negotiation and some other things that are really unnecessary when you just want a secure channel between two parties with pre-shared keys[1]. If you strip all those extra things from TLS you'll basically end up making your own protocol anyway.

What I'd like to see is a standardized protocol for this exact use case: two parties with pre-shared public keys, no algo negotiation[2], and only sending what's really needed over the wire without extra metadata. TLS is not quite right for this use case IMO.

[1] Yes, TLS-PSK exists but it's largely an afterthought and not always implemented by libraries, because it's considered a niche use case for TLS. To some degree, same thing can be said about client certificates.

[2] I think the article does say that they have algo negotiation in their custom implementation anyway. Personally I'd hardcode something like ChaCha20Poly1305, mainly because it's reasonably fast in software and on low-power devices.