Why does redirecting sed output to same input file make my machine unresponsive?

Your sed command was trying to read the file it was appending to. It will never reach End-Of-File, but will eat a lot of CPU time trying. That's why ^C (interrupt current process) was invented.

Appending back to the file you read from is in no case a good idea, as you will end up with an ever growing file. If you really want to write back into the file you should use the -i flag:

sed -i 's/original/edited/g' file.log

or if you want it to create a backup before doing changes you can add a file suffix to the -i flag:

sed -i.bak 's/original/edited/g' file.log

This would create a file called file.log.bak and then doing changes, what you did there by trying to append to the file you're reading from we call in programmer slang a data race, where different processes race for the same data source be it input or output. This is also why your machine came to a halt.

As has already been said, >> appends to the file, so your sed command will sit there reading the lines it has just output, and then outputting them some more. If you wanted to replace your file in-place, > still wouldn't work, but you're aware of sed's -i option, which is definitely the one you want.

If, however, you're absolutely sure that you want to append to a file you're reading as a stream, and only want to do one pass of this, consider using sponge from the moreutils package;

sed 's/original/edited/g' file.log | sponge >> file.log

sponge reads from stdin into memory until EOF, then dumps all its contents to stdout, so sed will hit the end of the file, stop reading it, close it, and then sponge will start appending to it.