I recently had to debug an issue due to the Java equivalent; the analysis is basically the same. Raising an exception anywhere including code that is not expecting it tends to cause subtle and unrepeatable bugs.
InterruptedException is better, but requires something closer to cooperative multi-tasking. If the thread is in a long-running loop that's not doing IO or it swallows the InterruptedException, you won't actually be able to kill the thread.
At work, someone had implemented an interface that let you kill a thread prior to my joining the company, so I found out that the warnings are very real when someone did that and it left the application unable to fetch DB connections.
InterruptedException is better but still handled incorrectly/badly in user code all the time. Sort of like interrupting processes: one process dying won’t corrupt the state of another, but the other process can continue on with bad assumptions.