A couple:
- Using EEPROM makes it possible to update the colors without having to recompile and reflash the keymap.
- I needed PROGMEM space, and the colormap was eating a fairly large chunk of it.
- It was easier to optimize the colormap storage in EEPROM than it was for PROGMEM. With EEPROM, it was easy to use only four bits per key, while the PROGMEM variant used eight. So storing it in EEPROM resulted in a more compact map.
Initially, Colormap supported up to 256 colors and a dynamically sized palette, it was limited to a 16-byte palette later on, to save space. At that point, it was easier to make the EEPROM variant more compact. I’m sure you’ll be interested in why, and the answer is pretty simple: for PROGMEM, I wanted an API that is easy to use, something that resembles the keymap definition itself (see this old example). While it would have been possible to write a macro that turns that into a structure that places two key colors into a single byte, I found that to be cumbersome. And since I wanted to save PROGMEM space anyway, and wanted to make the Colormap configurable via Focus anyway, I dropped the PROGMEM variant.