Earlier quoted context omitted.
The error correction is funny. If you don't use it, your message takes up less space, and the QR is smaller. If you have a fixed space to fit it in (e.g. printing to a sticker), that means your pixels can be physically bigger. For reliable reading, I found that physically bigger pixels helped more than the error correction itself. Depending on the length of your message, sometimes you can turn up the error correction…
Physically bigger pixels help a lot indeed. The encoding mode also helps make pixels bigger. This is very convenient when you control the QR reader and need to represent long numeric identifiers like UUIDs. For example: 9728983f-7d7d-4189-b624-f92781e36650 (lowercase UUID): => length=36, 15 pixels between markers JWM9GFVXFN0RKDH4Z4KR3RV6A0 (base32 UUID): => length=26, 11 pixels between markers 9728983F-7D7D-4189-B624…
-4J5BJ+%F$C881NIMV-IG2.C (base45, 132 bits in QR)
JWM9GFVXFN0RKDH4Z4KR3RV6A0 (base32, 143 bits in QR)
200924207194334734815443970355691218512 (decimal, 130 bits in QR)
It will make use of all allowed characters in the alphanumeric mode, while being significantly shorter than base32 and as dense as decimal. And decimal encoding in general needs bignum, because there is no suitable 10^k which is only slightly larger than powers of two so no convenient binary-to-decimal encoding exists (conversely, QR code itself does make use of the fact 2^10 is only slightly larger than 10^3 for this mode). Base45 always works on three-byte groups and maintains the similar efficiency in comparison.