I asked my question coming from the angle of big-oh analysis, and all three (as of the time of this reply) responses in the thread seem to describe a growth by a constant factor of 1.3bar, bar over 3, otherwise known as polynomial growth, yes?
Absolutely, the growth can be mathematically expressed with an exponent, but we verbally characterize the actual growth to be polynomial if the scalar stays constant (a.k.a. a literal number in the exponents place) rather than increasing as the amouny of input increases (independent variable lying within the actual exponent), no?
This part I cannot fathom. The era of 7-bit bytes is over. What can possibly justify the need for a "printable characters" encoding now? Something stupid like putting data in a JSON string? What's the next step, base-64 encode the JSON containing that string and put it in an XML tag?
<data><![CDATA[PD94bWw+PHdoeS8+PHRoaXNpc2F3ZnVsPjwvcm9vdD4=]]></data>
For example, there is (was?) a bug in nw.js with using @font-face to specify a font url that is in the same (local) location as the manifest. As a hack I tried specifying the font as a base64-encoded data url. It worked!
I had no use for base64, other than that there exists an interface for specifying data and it takes a base64-encoded string.
Bonus point if there's a situation where avoiding something like base64 is actually difficult, even in 2018.
Things can legitimately be encoded multiple times because encapsulation is a thing and multiple independent stages may each be configured to accept possibly binary input and produce base64 output.
You also don't need to re-encode something an unreasonable number of times to get "Vm0wd", all you have to do is start with "Vm0" and base64 encode it twice. "Vm0" only has 24 bits of entropy which means it will regularly occur at random in legitimate data.
And then nobody can figure out why "Vm0-Edge-West" isn't working.