That's the easy part. You can find a library that does exactly that, and only that. Will probably be just one file, not even a library [1].
But then you'll also need padding, MAC, signatures, key distribution, web of trust, etc.
[1] Example: https://github.com/dimview/speck_cipher
Furthermore, Speck has a variable block size between 32 and 128 bits. If you pick wrong, safe-looking things like CTR+HMAC-256 become unsafe (it's not hard to overflow a 32-bit counter).
The problem is, it's not nearly enough to just do Encrypt() and Decrypt(). Only when you see that, the benefits of a real crypto library NaCL become apparent.
Additionally, "bigger is better" is not a reasonable way to pick primitives. Defaults matter. Perf matters. From experience and stats, people pick according those two vectors a lot more often than they pick along the "bigger is better" axis. When's the last time you saw an RSA-16384 signature? AES-256 might have twice as big a number as AES-128, but how much faith do you have in that extended key expansion? You use AES-128 a lot more often than you use AES-256, and you definitely use RSA-2048 a lot more often than RSA-16384.
I don't think you can responsibly insist that this was an answer to the question. It is not a secure way to encrypt messages.
Complexity begins when you try doing something more involved than just symmetric block encryption.
I think I sort of see your point, but SPECK is a weird recommendation.
How is the IV stored for example.
Don't roll your own crypto.
Once you start adding things like CTR mode, MAC, etc. the API is no longer as simple.