Two different questions, so two answers.
Why SPECK and SIMON are small: both are ARX designs (add, rotate, xor) with no S-boxes. AES needs lookup tables or a fairly involved byte substitution, which costs flash and RAM on an 8-bit part and leaks timing if you do it with tables. SPECK’s round is a handful of 16/32/64-bit adds, rotates and xors, so a full implementation fits in a few hundred bytes. There are two because they were tuned for different targets: SIMON for hardware (very few gates), SPECK for software on microcontrollers. They also come in many block and key sizes (32/64 up to 128/256), which is handy for tiny packets. For your thesis, the ISO standardisation fight and the missing design rationale are worth a chapter too.
Why you can’t swap TLS for SPECK: a block cipher is one building block. TLS gives you key exchange, server authentication and message integrity, and the platform checks your credential inside that session. If you encrypt a payload with SPECK and send it, someone still has to agree a key with you and the broker would see an opaque blob. On Hermetry the device side is TLS 1.2 minimum (1.3 preferred) with forward-secret suites: AES-GCM or ChaCha20-Poly1305, no RSA key exchange, no CBC. Plain MQTT on 1883 only works if an admin switches Plain MQTT on for the profile, and the docs treat that as an exception for devices that can’t do TLS on a private network or VPN. That’s why your 1883 test was refused. It’s all on the device transport security page.
Practical side: the ESP32 has AES hardware, TLS costs you a bit of RAM and a second or so of handshake per connection, and after that it’s nothing you’d notice at sensor rates. The ATmega is the honest problem. Either use ChaCha20-Poly1305 thinking (it’s ARX too and fast without hardware), or let the ATmega talk to a gateway that holds the TLS session.