I wouldn't expect the difference to be too significant, once the connection is set up.
A breakdown of the overhead that TLS produces in general can be found here. The important bits are:
- The total overhead to establish a new TLS session comes to about 6.5k bytes on average
- The total overhead to resume an existing TLS session comes to about 330 bytes on average
- The total overhead of the encrypted data is about 40 bytes (20 + 15 + 5)
- It is easy to modify the above calculations to reflect more precisely the specifics of an environment, so this should be considered a basis for TLS overhead and not the authoritative answer to the question posed.
It's worth a read to see how these figures were calculated—you should come out with a greater understanding of how TLS works with all of that. As noted in other answers, the radio transmission is likely to be one of the biggest uses of energy, which is often a constraint in the IoT, so once the session is established, the overhead isn't too significant, particularly if your messages are not trivially short.
As noted by HiveMQ in the article How does TLS affect MQTT performance?:
The good news is, that a MQTT client only needs to establish a connection once per session – in contrary to protocols like HTTP, which needs to re-establish a connection on every request (if no keep-alive is used or other techniques like Long Polling are in place). Once connected to the broker, the client can send and receive messages without any additional handshake overhead. The use of TLS needs to allocate additional buffers, so RAM consumption is also slightly higher per MQTT connection.
They also provide a graph of CPU utilisation on the broker when 50,000 clients connect:
Image Source: HiveMQ (see above linked article)
Do note that this is almost certainly not a typical usage pattern, but the data is nevertheless interesting. As you can see, there is a large overhead while the handshakes are in progress, but after that, the CPU overhead is nearly identical. I would expect a similar thing on the client.
Still, the general advice here is correct: a contrived benchmark won't give you the information you really need; to know how TLS will affect your use case, you need to test it in... your use case!