You really don't have any big need/use for memory protection with a SPI-connected EEPROM.

If your code constains "unlock, write, lock", then a crashing application that does manage to reach the "write" code will quite likely manage to find the full sequence - including the unlock/lock.

Memory protection is most important for:
- making sure people doesn't accidentally erase the boot loader, if using programming tools to replace an application.
- making sure that a parallell-connected EEPROM with direct writes doesn't get damaged by a random write caused by a pointer error.

Remember that for SPI, it isn't enough to just manage to toggle the SPI signals.

If you do need protection, you are best off locking the access to the slave-select signal to the EEPROM.

Yes, if you do continuously perform EEPROM reads, and have bad signal integrity, then a bit error could convert a read operation into a write operation. But you should obviously make sure that you don't have bad signal integrity. Problems with the signals may convert a good write into a bad write (wrong address, or wrong data) or a good read into a bad read. None of which will be covered by any unlock/lock.

Yes, if the cells for protection are non-volatile, then it is likely that they support the same amount of write cycles as the rest of the memory cycles.