Yes but both processes write to EECR.I think we have here two separate processes:
The datasheet is a bit confusing about SBI and CBI:
In several places it states that these instructions can affect bits that are "triggered" in some way by writing a 1 regardless it previous state, for example some interrupt flags.
Some of the Status Flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on all bits in the I/O Register, writing a one back into any flag read as set, thus clearing the flag.
All AVR ports have true Read-Modify-Write functionality when used as general digital I/O ports. This means that the direction of one port pin can be changed without unintentionally changing the direction of any other pin with the SBI and CBI instructions. The same applies when changing drive value (if configured as output) or enabling/disabling of pull-up resistors (if configured as input).
Do not use Read-Modify-Write instructions (SBI and CBI) to set or clear the MPCM bit. The MPCM bit shares the same I/O location as the TXC Flag and this might accidentally be cleared when using SBI or CBI instructions.
Beware that if doing a Read-Modify-Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI instructions are used.
This suggest that if EECR is 0000 0001 and you write 0000 0101 (SBI EECR, EEMWE) then it can trigger a read operation.
But reading many discussions in the internet seems that this was the case at the beginning but it was "corrected" later and today SBI and CBI never affect other bits, but the datasheets are not updated.
Let me know what you find please.Although I didn't have the idea to check that EERE is reset by hardware soon after reading the byte from EEPROM [during the 4-cycle reading instruction], I think it is the case. But I will check this by running the ATMEL Studio simulator (just to be 100% sure).
If this issue don't let you test other things you can clear EERE by software after a read, and it should work ok, but eeprom write times for Atmega8 might be wrong.