Yes you always end up modifying the same byte(s) as soon as one of the byte in the payload changed.
When I know something can change very often I use a capacitor + power detector trick to only save the data upon power loss and in the mean time I keep the data in RAM (and possibly save once a day sometimes).
But my point is, the checksum/whatever always modifies the same memory locations, whereas hopefully data changes are spread across the dataset. For example, on my servos, the thing that would change most frequently would be servo travel endpoints; but, with 16 servos on a Nano, I would expect that changes would be somewhat randomly spread across the 32 stored setpoints, but a checksum would always be the same location. So the checksum location would wear out long before any of the setpoint locations. Admittedly, this will not necessarily be the case in other implementations.
But, it's somewhat moot; so far, once installed, I've not had to adjust my servos. Only 8 months in, though, and I haven't looked recently to see if anyone's getting sloppy, or overdriven; I should do that, as seasonal changes are the most likely source of problems.
Fair enough. Solution could be a CRC per record; might be expensive in storage but reliability comes at a cost.
And with the rate that you currently update the servo records you will have an (near) endless life for your EEPROM 
Thanks for all the information. I understand now the process.