For instance, re-writing code in flash and jumping at a specific location is what every bootloader is doing right now. The problems are:
a. The bootloader has to know where to jump, so this information has to be saved somewhere (in 99% of cases this address is hardwired). If my code can be loaded at an arbitrary position in flash, then I have to "remember where" by saving the address in flash.
b. Flash sectors are usually big and they have to be erased by sector (so writing any new information, even a byte, requires blowing up and wasting an entire 16K sector, for example).
So if the idea is either to update, in flash, a piece of code, a single function or the entire program firmware, it requires erasing and writing sectors in multiple of 16KB (and this number is getting bigger as flash size increases).
Still, if there is a workaround for this, then thinking "it's practical to have relocatable code because the code is updated at every boot so we always have the latest version" is the wrong approach since there is a finite number of times one can write in flash before it gets damaged.
Also, the article is about Cortex-M, so we have to think about the vector table. Address on the vector table cannot be "relocatable" as these are fetched as-is and not translated. So now you have to point all your interrupts to a single interrupt vector that gets the interrupt type, searches the correct function, translates it, and then jump to it.
It's also true that you can relocate the vector table in RAM, so you can modify these address on the fly, but that's extra work.
At the end of the day, you'll be better playing around with linker scripts and updating programs or pieces of code by pointing to known addresses (sections) from the linker script.
Edit: I didn't mean to say that relocatable code is just about writing on flash at every boot. Instead I wanted to point out that relocatable could lead to this idea.