Instead of thinking all the things you shouldn't do and 'just saying no', what about the things reasonable that may deserve a 'yes'? An open approach instead of closed?
Yes, but writing to flash (program memory) at runtime isn't really a desirable thing to do. Sure, we can be open about it. But if you do it 10 times a day, and the flash can be written to 10,000 times, your app will fail after 3 years.
It might be. There are some legitimate uses to overwrite the running code in flash.
With respect to the number of writes, it depends on where the write(s) is done.
The 10,000 times is per page. If you are updating the flash with a minimal
change it will potentially only impact a single page. Since there are many pages in flash the actual number
of writes could be much higher than 10,000 times if the writes are being done on different pages.
Plus, it would be easy, if you enable writing to flash, to corrupt the running program. Do you want that?
I could think of reason to want to do this: Debugging.
Suppose you want to run gdb for source level debugging and insert a break point.
The way to do this is to "corrupt" the running code with a new bit of code where you
want the breakpoint to be.
The Atmel ICE products do this by "corrupting" (overwriting) the existing code
with a BREAK instruction. They read the appropriate flash page
and re-write the page with the BREAK instruction inserted in the correct place.
It is possible to do the same (overwrite code with a special instruction)
without an ICE in the code itself to allow gdb to talk to through the serial port on the AVR by
using a similar approach. You can't use the BREAK instruction because that is reserved by ATMEL when
the OCDEN fuse enables 1 wire debugging (debugwire).
You can do it through a cleaver use of an instruction to trigger a hardware interrupt
(INT0 is best to gain full control) to cause a trap into an ISR.
From there the code can take over and talk out the serial port and eventually
back to gdb to transfer all the relevant information using gdbmon messages.
Yes it is a bit tricky and it does require the ability to overwrite flash pages
but it allows using the AVR serial port for source level debugging.
It also requires a custom version of gdb to modify the "breakpoint" instruction
to the needed instruction opcode to trigger the interrupt because currently the opcode
for the "breakpoint" instruction is hard coded into gdb as BREAK and BREAK
can't be used since it only works for debugwire.