Timer 1 (16 bit): Why is overflow interrupt sometimes missed?
The problem is that you are not eliminating the actual issue with the ATOMIC statement- the counter is incrementing in hardware and there will be times when an interrupt is pending but not completed. It's worse because the C int operations take a lot of cycles on an 8-bit processor, but it would show up even in tight asm code. 

If you don't have any other interrupts of much duration going on you don't even have to kill interrupts, you can simply correct the count. 

The general approach is as follows:


read timer1OverflowCount, first timer1OverflowCount sample 
read the hardware counter TCNT1  &lt;-- right here is when you are sampling with high resolution
read timer1OverflowCount again, second timer1OverflowCount sample 


If timer1OverflowCount has changed (incremented), then look at the sample from TCNT1. If it has MSB = 0 then use the later timer1OverflowCount. If it has MSB=1 then use the earlier timer1OverflowCount. 

There is no need to turn interrupts off unless there are other interrupts with slow ISRs going on that could cause the total time for the above to approach the time for the hardware counter to reach 1/2 of full count. It's almost always undesirable to turn off interrupts unless absolutely necessary. 

Edit: In your case you have an int for the overflow so you need to make the read of the variable changed within the ISR atomic, as well as dealing with the issue above.