The difference is that it takes the overhead of saving all the PBP system variables into account. There's nothing you can do about the non linearity really - it's just the way it is. One way to reduce the effect of it is to have less "steps" in the SIN table, that willm bring the interrupt frequency down which makes the relationship between interrupt frequency and reload value more linear.

You CAN calculate the reload value at runtime, Darrels timer template even shows you HOW to do it (at compile/assembly time) but you need to play some tricks to do it runtime. The following is NOT tested:
Code:
Dummy VAR WORD
Dummy2 VAR WORD
Dummy3 VAR WORD
ReloadInstructions VAR BYTE
TimerReload VAR WORD
Frequency VAR WORD

ReloadInstruction = 0  'Number of instructioncycles it takes to actually reload the timer. I don't know how many it is in this case. Tune later.

'For 40Mhz operation and 1:1 prescaler the timer ticks at 10Mhz
Dummy2 = 10000     'These can not be constants because 
Dummy3 = 10000     'constants doesn't work with DIV32

Frequency = 200    'Lowest possible frequency is ~153Hz. Don't go below that.

Dummy = Dummy2 * Dummy3        'Intermediate result is now 10.000.000
TimerReload = DIV32 Frequency       'Divide 10.000.000 in Frequency (200 in this case) 
TimerReload = 65535 - TimerReload + 1 + ReloadInstructions  ' =15536 for 200Hz

'Reloading the timer with 15536 makes it time out in 50000 ticks, one tick is 0.1us so
'it times out it 5000us or 5ms, 1/0.005=200Hz which is the frequency we wanted.
This should calculate the reload value, at runtime (don't do this IN the interrupt service routine). But I don't think you'll get 0.1Hz resolution at the top end.