Sorry, that could have used more explanation, especially since I'm really hypothesizing after the fact about
why it works better to start fast and end slow, and that hypothesis involves a few steps of inference.
It's pretty clear that the human brain is good at simple integration over time to predict where an object will be in the future, or how long it will take to reach a destination. What it doesn't seem to be as adept at is estimating those things when something is changing speed. I would guess that the reason for this is a combination of the math being harder, the results being more noise-sensitive, and it being less crucial in our evolution to anticipate rapidly accelerating or decelerating targets.
So my first premise is that we estimate time-to-destination based on speed, and that we are slow to update the estimate when the object changes speed.
My second premise is that time perception is heavily influenced by expectation. If click something and then nothing happens for a moment, our wait-time expectation is essentially unbounded, since we aren't even reasonably sure that anything is happening.
If you add a spinner, we become more confident that the wait will end, but the time expectation is still high. If the spinner lingers for too long, our only way to update the expectation is something like "I will be waiting for some significant proportion of the amount of time I've been waiting so far". That's not good, because it actually causes your expectations to invert with respect to reality; as time goes on, you feel further from the end, not closer.
So the idea is that a progress bar feels faster because it gives a decreasing expectation of time left. If the progress bar is accurate, then once it has moved half way, you will expect to wait exactly as long as you have already waited.
Now, the trick with the decelerating progress bar is that it lets you beat accurate expectations by causing the user to underestimate how long they will be waiting.
For example, suppose you accurately estimate that it will take 6 seconds. In the first two seconds, the progress bar will fill, about linearly, to 40%. The user will therefore expect the bar to be full after 5 seconds. After 4.5 seconds, it will be 75% full. If the user were to estimate based on there entire time so far, they'd correctly expect to wait another 1.5 seconds. But that doesn't seem to be what happens. Instead, the user continues to expect less. And so on. In the final moments before the progress bar disappears, the user simply doesn't have time to adjust their expectations.
What seems to lend additional credence to this hypothesis is that you can get even better results by adding random slowdowns and speed ups (while maintaining an average fill curve of erf(erf^-1(estimate)*t/estimate)). When the bar passes the 75% mark where it slows down for good, the user still expects another jump. You can even confirm this expectation by filling the bar at the end it disappears, since at expected completion it will only be 87% full.