i'm pretty sure it relates to optimization of the amount of counting and comparing

see this code for an example of a base 10 encoder

https://github.com/mleku/realy/blob/dev/ints/ints.go

you see the chunking i've used, this accelerates the decoding process, because you can just create an index table of short words that you can scan by magnitude and then immediately grab the encoded chunk that corresponds to it

you can also find similar chunking schemes used in the go standard library for multiple precision but when you have a fixed precision, you have a symbol unit length and every single time you parse a chunk you have to make decisions, by adding padding, you eliminate the need for those decisions, you can eliminate them with one size test - a modulus and comparision

base64 provides for storing 48 bits in 64 bits of data, so it has a word length of 64 and i think most usually would entail a lookup table of probably 12 bits per symbol, or 64k of symbols each two bytes for the code and 2 bytes for the (must be concatenated) fragment of the represented data

this thing about 64 bit words in modern CPUs is a huge part of why there is padding