Several of the answers on stackexchange and comments here are absurd.
SIGKILL shouldn't be your first resort but sometimes is necessary as a last resort. If the sky falls and you can't deal with it, there's something wrong in a lot of places which have nothing to do with signals.
But 'nuclear option' attaches too much meaning, if you're in the position, you'll run into plenty of circumstances where SIGKILL is necessary. It's a perfectly fine tool to use and deserves no extremist opinions.
Right... In Windows and OSX you have to do the same thing fairly often. It's called "force quit" or something like that. Otherwise you'd sometimes be waiting an eternity for programs to get themselves unstuck. If a program leaves a messy state behind when you `kill -9` it, it will automatically clean up the mess the next time it runs. If it doesn't, then don't bother using it, because it's extremely poorly written. (If there are orphaned child processes left behind, I kill them manually.)
Usually it's just an obviously good idea to send a milder signal first, because it's less likely to leave orphaned child processes and `kill 345` is just plain easier to type than `kill -9 345`. Also, trying a TERM signal first gives you some feedback on how fubar the process really is.
Yeah, Windows has "Force Quit" baked into their regular shutdown process now - if any program is blocking the shutdown for more than a second or three, the user will get the option to kill everything. Under windows, there is now no excuse not to properly handle a forced abrupt termination, because the layman users will do it.
I always looked at it like: I have tried to stop / shutdown this program in the documented way, then I tried a kill -15, but this thing won't go so kill -9. I then think very hard about why I allow such a thing on a system.
SIGKILL shouldn't be your first resort but sometimes is necessary as a last resort. If the sky falls and you can't deal with it, there's something wrong in a lot of places which have nothing to do with signals.