Not implementing the RFC, is not implementing Base32, changing the order, or using 32 emoji does not make it Base32. Put another way, you can change the order of characters in Base64, or use a different dictionary, and indeed there are several variants of that too (BinHex4, Uuencoding, Base64Url, B64) - there are specific implementation detail concerns there too.

Base64 won out as a reasonably dense way to encode binary data in 7-bit safe ASCII for use in email, and later http headers (where spacing and line length may be modified in transit, and some ASCII characters are prohibited - eg 0x00/null). Part of the reason is; bit-grouping makes encode/decode simpler (you can use bit shifting). Something like ASCII85/Base85 which is a more dense encoding, and close to the maximum you can get in 7 bit safe ASCII (94 characters 33-126 if space is important, 95 if space quantity can be preserved) but you have to use multiply/divide instructions. The union of bit-shift speed (power of 2) and 7-bit safe ASCII characters (max 94 values) is: binary, base4, octal, hexadecimal, base32, and base64.

For human readability, especially verbal communication, hexadecimal or base32 are advantageous in that they are more dense than decimal, can be generated via bit-shifting vs more complex processor instructions, but you needn't also communicate the character's case (unlike Base64).