There can't be an exhaustive mathematical proof of the seed file refresh rate as there isn't any exact assessment of entropy generation within a generic computer thingie.
Most of the entropy on my desktop comes from typing this answer. If you leave the machine alone, entropy generation rate can be much lower than 1 bit /s. This rate was empirically measured, but internally relies on entropy being quantified in jiffies which aren't exactly SI units of anything. Even this is uncertain as there is no accurate quantitative assessment in the literature. Realistically there can't be because if a computer isn't doing anything, there's no entropy generation. And if you're playing Halo, the entropy rate is very high as you pummel the key board and IO system.
Anecdotal evidence leads me to be personally sceptical that a random Fortuna input event contains 8 bits of true entropy as suggested. A great deal of the security proofs of Fortuna revolve around this groundless assumption.
I'm almost certain that the figure is pulled out of the air which is supported by the "A reasonable solution would be to rewrite the seed file at every shutdown and every 10 minutes or so" assertion. That's as good as anything else. Similarly the 1 MB max output stipulation is probably just what looks nice and rounded as it's "not an inflexible restriction".
A simple example is to consider a machine equipped with a true random number generator. Say one of those DIY efforts that reads unconnected sound noise. A seed file would be entirely unnecessary as adequate entropy could easily be gathered from the sound card. Ergo reseed time = ∞.
A seed file that's always younger than 10 minutes gives Fortuna something to work with for seeding the pools at start up. Computers are notoriously short of entropy at start up. If you can't accurately measure the entropy generation rate, you therefore can't develop an accurate relationship to how often that entropy should be persisted for the other side of a reboot. You could change it to every hour.