The proces is already dead at the time. It doesn't make sense to kill it again. It is still recorded in the process table to allow the parent ti pick up its status.
Note that all processes become zombies after being killed. You just don't see them because most parent processes clean up their children very quickly. You might want to file a bug report if a software doesn't clean up its zombies and they only get clean up by init once the parent process exits.
Your additional question is why SIGKILL doesn't remove it from the process table. You should first tell us why it should. I'm not aware of any single reason to let the user remove a defunct process from the process table. In operating system design, you should always have a good reason to do something before you ask why not to do it. You're asking for a feature with no actual use case.
Apart from the lack of purpose, it would have bad consequences. The parent calls wait() and/or waitpid() to learn the status of the children that exited. The result of the call is consistent whether it is called before the process becomes defunct, before you issue the SIGKILL, or after that.
If the kernel didn't keep the records (i.e. the process would be removed from the process table), the behavior would have to be inconsistent and the parent would have to expect the inconsistency and cope with it for no valid reason. In systems that would reuse old pid values, not keeping the records could result in much more severe problems like a software killing an entirely different process by accident.