Why is there a maximum time for length of write pulse to write on an EEPROM?
I assume your question relates to parallel EEPROMs.
The Write pulse (time) is a minimum specification and typically has no upper bound. In other words the time specified limits the speed of writing (bits/bytes/words per second), but the chips will operate at any lower write rate.
For example here is the datasheet for the 26C64 write timing:
Notice there is no upper bound for any of the chip select or write timing.
Addition:
The 28C16 you raised in the comments shows a limitation of the early EEPROMs ...they needed a higher write voltage for the cell write/erase cycle.
This meant they could not work down to DC (the lowest freq of write cycle possible).
There are two reasons I can think of for having a limit to the write pulse length:
If the part uses dynamic latches to hold the address, those latches may only be able to hold their value for a certain length of time. Since the address is latched on the falling edge of /CE & /WE, but the write doesn't start until the rising edge, giving the chip a write command that's long relative to the time required to complete a write cycle could result in the dynamic latches forgetting the address before the write cycle is complete.
If the device rejects any write cycles that are excessively long, that may help guard against erroneous write operations in cases where a system operation gets disrupted (e.g. by loss of power). If that were the intended purpose, however, I would expect a specification that would indicate that write pulses within a certain range are guaranteed to be accepted, write pulses that are outside a larger range would be guaranteed to be ignored, and those between the two ranges might arbitrarily be accepted or ignored.
In either case, 1000ns seems like a curiously short maximum. The address needs to be held for an entire write cycle, so any dynamic latches would need to be able to deal with that. If the cycle limit is intended to guard against stray write events, engineering it to be usable with systems that run at slow clock speeds should have been trivial and would have improved usability.