Ignoring the value of $n$, focus on the length of $n$.
Here I'm interested in the decimal representation of input and outputs.
Example
For $2^n$, $n=15$.
- The solution for $2$^$15$ is $32768$.
- The length of $n$ is two digits and the solution is $3$ digits longer.
Another example is $2$^$100$
- The solution is $1267650600228229401496703205376$.
- The length of this large number is $31$ digits. And $n$ is $28$ digits shorter.
When solving this problem the digits returned on-screen are exponentially larger compared to the length of $n$.
Question
What examples can be given for how the digits expand exponentially over-time?
It might help if you gave a name to the size of your input. If the size you are concerned with is the number of digits of $n$, not the value, then let $d$ be the number of digits of input. In that case, the number of digits of output when you take a decimal number of $d$ digits, raise $2$ to that power, and write the result as a decimal number, will be between $0.03\times10^d$ and $0.3\times10^d.$
For example, if the input is $9$, then $d = 1$, the output is $512,$ which is $3$ digits of output, and $3 = 0.3 \times 10^1 = 0.3 \times 10^d,$ at the high end of the range predicted by "between $0.03\times10^d$ and $0.3\times10^d.$"
On the other hand, with an input of $100,$ you have $d = 3,$ and the output (as you found) has $31$ digits. In this case $31 = 0.031 \times 10^3 = 0.031 \times 10^d,$ so it's near the low end of the range.
For $d= 10,$ the smallest result is when the input is $1{,}000{,}000{,}000$, in which case the output, $2^{1{,}000{,}000{,}000}$ in decimal representation, has $301{,}029{,}995 > 0.03 \times 10^{10} = 0.03 \times 10^d$ digits. Just to store the output on a computer (never mind displaying or printing it) requires nearly $300$ MB of storage.
Now let's try an example with $d = 20.$ The number $20$ isn't what most people would consider a huge number. But the smallest $20$-digit decimal number is $10{,}000{,}000{,}000{,}000{,}000{,}000.$ And if you wanted to write the answer to the decimal representation of $2^{10{,}000{,}000{,}000{,}000{,}000{,}000},$ you would need to write a decimal number with $3{,}010{,}299{,}956{,}639{,}811{,}952 > 0.03 \times 10^{20} = 0.03 \times 10^d$ digits. Just to store the output, you would need about $30000$ $100$-TB storage drives.
If we increase the size of the input to $d = 25,$ you need to compute the decimal representation of $2^{1{,}000{,}000{,}000{,}000{,}000{,}000{,}000{,}000}$ or something larger, with at least $301{,}029{,}995{,}663{,}981{,}195{,}213{,}738 > 0.03 \times 10^{25} = 0.03 \times 10^d$ digits, and now you need $300$ million of those $100$-TB storage drives just to store the answer.
So if your algorithm is supposed to write the decimal representation of $2^n$ where $n$ is a decimal number of $d$ digits, the size of the output is proportional to $10^d$ and it becomes quite impractical just to store the output, let alone compute it, for values of $d$ that are only about $20$ or so.
In summary, if you measure the "size of input" by the number of bits, for example if we expect the input to be a random string of $d$ base-ten digits, any exponentiation algorithm is going to blow up as soon as the input gets much longer than a dozen digits, possibly sooner.
On the other hand, there aren't a lot of practical exponentiation problems where we're interested in answers for powers much above $1000$ ($d = 4$). I would question whether it makes sense to measure the time complexity of an exponentiation algorithm using the same criterion (length of input in bits) as we do for a sorting algorithm. It seems to me the complexity of exponentiation as a function of the number of bits of input is really interesting only to a handful of theoretical computer scientists, unlike the complexity of a typical sorting algorithm, which has many very practical consequences.