I have not tested the following, but it is a viable theory:
when sed (and presumably perl too) modifies a file it has to create an intermediate file. This is because of its modus operandi: it reads from the source file, modifies the read part and writes this modified version to the target file (screen or new file). This is why you usually do:
sed '<something>' /path/to/source > /path/to/target
mv /path/to/target /path/to/source
although this looks cumbersome. Notice that
sed '<something>' /path/to/source > /path/to/source
won't work, because sed would read the first line, modify it, then write it back to the file it just read from and further tries to read from it now won't be successful any more.
This is why Linux (/GNU-) versions of sed and perl extended the options of the original sed to the "-i" switch, which does just that: automatically replacing the input file and making the second command variant working.
Still this doesn't change the working of sed and the trick with which the "-i" switch is implemented is to create a (hidden) temporary output file and move that over the original file after the modification. In fact "-i" is just automating the "mv"-command in my first example. If you start a long-running sed job you will probably find the intermediate file somewhere in /tmp , /var/tmp or some similar place while the job runs.
It may well be that this doesn't honor soft links because a new file is created and then moved in place, replacing the inode of the softlink.