I doubt you'll get a common concensus/answer to your question. Each manufacturer have different approaches to FW development and in reality, manufacturer's recommendations are really just recommendations and developers may or may not follow them exactly especially if it is something that will not have a
direct/apparent effect on the operation of the application. And if development is done properly, there are many ways to circumvent reaching the write/erase limits throughout the lifetime of the product, one common and easy way of which is buffering or intermittent flushing, which significantly reduces the write/erase cycles. Though, there is no way to tell this from the end-product itself nor stated in the datasheets.
On the bright side, for this type of application (i.e. storage of FW and/or user config), running thru the write/erase spec should be the least of your worries for the flash memory. And unless you're using parts from the bleeding edge of flash process/technology or the really really cheap ones with not much quality testing at all, semiconductor manufacturing is now at a pretty mature point that products are usually reliable and failures are in the low ppm range. And besides, it's not like you're going to change settings a thousand times and do it every single day, right?
P.S. I test flash memory for a living - NOR flash memories to be exact, the kind that gets embedded into microcontrollers and custom ASICs.
And one more thing - welcome to the EEVBlog forum!