I cannot answer the question from a game design standpoint, and I suspect the real answer lies there. Hopefully someone will be able to preempt my answer here with that perspective.
Or does it actually require some kind of "expensive" mathematical calculation which earlier (arcade) hardware simply didn't live up to?
Such calculations are not particularly difficult. They would not use up very many processor cycles. Various ways to apply a curve to the acceleration rate would have been obvious to programmers at the time, if they wanted to implement such a feature.
The main limitation would be ROM space used for the routines. ROM was at an extreme premium on the earliest arcade platforms and consoles. Some of the earliest microprocessor-based arcade games had as little as 1 KB of ROM. The total number of instructions you can fit in that much space is measured in the hundreds.
Even by 1982, most games for the Atari 2600 are 4 or 8 KB and big arcade games were weighing in around 32 KB. Released in 1985, the Super Mario Bros. cartridge had 40 KB total of ROM. The designers would have been far less constrained, compared to even just a couple years before, when it comes to things like a couple dozen instructions to implement the feature you mention.