While most flash memories use a different circuit topology from most EEPROMs (some devices using the EEPROM circuit topology are marketed as flash, and perhaps vice versa), many EEPROM memories have long been subject to operational limitations similar to flash, to wit:
It's possible to change bits within individual bytes from "1" to "0", but the only way to convert "0"'s to "1"'s is to erase large blocks at a time.
Performance, and eventually reliability, of blocks will degrade with each erase cycle.
Thus, for essentially as long as EEPROM memories have existed, it has been necessary for software to deal with these constraints. If the EEPROM was being used to hold a set of parameters that would be unlikely to change even a dozen times during the lifetime of a device, and never more than a few hundred, it would be fine for software to simply erase and rewrite the same block every time the parameters were changed even if the memory was only rated to be usable through 1,000 program/erase cycles. If, however, a device would be used to hold a counter that would be updated once per minute, even 10,000 write/erase cycles wouldn't be enough for such a design to last even a week.
Note that if a device had e.g. four separately erasable 256-byte blocks, and was unlikely to lose power while changing its configuration, it could use one block to hold the configuration and use the other three blocks in rotating sequence to hold the last multiple of 128 counts, along with 240 bytes that were used individually to mark off individual minutes. Every time those 240 bytes got full, the system would need to erase and reprogram the next block in rotation. This would reduce the stress on each block from being programmed and erased once every minute to being programmed and erased about once every 12 hours. If each block can only be programmed 10,000 times the device would wear out after about 13.5 years, but that's a huge improvement over lasting less than a week.
Historically, software to manage flash or EEPROM memory would often partition it into various regions, and use wear leveling only when storing frequently-updated data. Flash drives, however, generally use a more unified wear-leveling approach which manages everything. Doing that would often require using a fair amount of RAM to keep track of where many individual pieces of data are presently located, but as RAM prices have decreased such an approach has become more practical. This wasn't a sudden design change, however. Instead, the fraction of devices using such approaches gradually increased as adequate RAM would more often be available to handle it.