I hope I haven't got my numbers out by an order of magnitude here
Just looking at the three numbers you've got above
The difference in period between those three is < 1uS.
The "ISR"s you have aren't really ISRs at all, they are functions called by the the real INTx ISR, however as the real ISR doesn't re enable interrupts they are effectively the same thing but with a higher overhead.
Given that these two interrupts are asynchronous with the program and each other I reckon there are two potential issues.
a) The interrupt latency is variable, and with tolerances as tight as you have this could easily make a difference, ie the difference between getting a count of 7.543KHz and 7.530Khz 228nS or about 3-4 processor cycles.
b) If you are in INT0 and get INT1 (or VV) then the second interrupt will be ignored until you finish the first, meanwhile the timer is happily ticking away. Likewise if you are in the millis() interrupt.
I'm not convinced this can be totally overcome, but changing the "ISR" to something that did almost nothing like
volatile byte INPUT1_t;
volatile byte new_count_1;
INPUT1_t = TCNT0;
new_count_1 = true; // set flag for external processing to occur
and doing all the other work in the main loop would have to help. At least then there's less chance of interrupts clashing. But there's still a chance and you have a double whammy, the higher the frequency the more likely to clash and the more affect it has on the count.
Interrupts are fine but they do introduce these sort of issues.
I think for high-speed counts using pulseIn() may be a better option. It is blocking but it sounds like you have known times, say directly after servicing the i2c protocol with the master, where you can afford to concentrate on this.
As pulseIn() does nothing but look at the state of a pin it is very deterministic, I would also kill interrupts around the pulsIn() call, this will affect millis() and maybe other things but you don't need them by the look of the program.
If the gadget is supposed to measure a large range of periods then a two-pronged approach may be the idea. PulseIn() for high speed and the other for low speed. Of course with pulseIn() you would have to measure both mark and space periods and add them together.