I prefer "real" byte-writeable EEPROM or F-RAM when I can.

But if I do have to use flash instead, I would go two routes depending on need.

For configuration, changes would be seldom needed so I would do a sector rewrite. Note that some chips do not support multiple writes to the same flash sector without an erase because they have hidden ECC bytes. So while it is possible to toggle bits within the page, this would result in corrupt ECC data. If I can, I would use two sectors and store a counter in each sector, and alternate between the two sectors. So if a write fails, I can fallback to the content from the previous write.

For a data logger, I would make sure that the flash do support enough number of writes (number of writes for each sector, and total number of sectors to spread the writes over). And I would cache enough data to write a significant amount of data. Potentially not filling the sector but then performing multiple partial-sector writes to different sectors and when I have enough data to fill a full sector I would consolidate the data into a new sector, and then continue forward in the flash with more partial writes. This way, I could spread the number of writes more evenly. Obviously, I need to store a little header at the start of each sector, to let a rebooted program figure out what the stateis of all sectors, and continue with the current wear-leveling pattern.

But for a data logger, I would really prefer to write to a memory card with an integrated controller that does wear-leveling. It reduces lots of complexity.