I don't ever recall seeing an actual calculation for it, and I strongly suspect the reason is that it is "good enough".
The original, primary use of block timestamps is in difficulty calculations. They now also adjust the time for locktime transactions, but that's a newer addition.
A block's timestamps must:
- Be greater than the median of the past 11 blocks (11 also seems to be a number chosen because it's good enough)
- Within 2 hours of the network adjusted time
The network adjusted time is calculated by asking all your peers for their UTC timestamps, and if it's within 70 minutes of your own node, updating a network adjusted time median calculation over all the node times.
This imposes limits on how much a single node or miner can influence the time related parameters. Since difficulty adjustments look at the time between blocks and adjust to bring the mean down or up to 10 minutes, allowing for a very large variance may be counterproductive. 2 hours (to me) seems like a reasonable amount, since even if someone confuses DST time settings and has a bad clock, they would still be off in the range of 1-2 hours, on a reasonable system.
Of course, with ntp and other timekeeping services these days, nodes should be off a lot less. I've never heard of the 2 hour limit being insufficient, or of it being too large and causing issues with difficulty readjustment.
There are several things in the Bitcoin spec that exist because that's the way it was set up in the original implementation, and no pressing reason exists to change it.