The folks at Uber who built this did originally reap the leaked goroutines. You can see this in the paper they published on it; it's certainly possible.
There are a lot of questions that come up with reaping leaked goroutines. For one, do you run its defers? Is it OK to do so? You'll probably make some heap memory unreachable too by reaping goroutines (great!), so finalizers/cleanups will run. Are they safe to run? Is the program expecting it? What if there's an explicit runtime.KeepAlive over the code block it's stuck in because it's doing something scary? If we don't run finalizers/cleanup/defers, then do we just leak other resources, like file descriptors?
Most of the time it's fine to do this. But to summarize the concern, reaping goroutines out from under the program risks generating new hard-to-debug failure modes. Worse, there's no evidence left behind of the reaped goroutine. You could keep a stack trace behind, maybe, but that's still sort of a second-order diagnostic; how would you know to look for that without experience? Leaks are much louder, and may reflect other bugs in the program. Finalizers/cleanups are hard enough because they can run at any time, this would be kind of a new way through which code could run at any time, if we wanted to really clean up.
Don't take this as me or the Go team saying "never." My point is that there's just a much clearer purely positive benefit with a diagnostic. I think automatic reaping has enough possible negatives that it requires more thought. But it is definitely possible!
https://lobste.rs/c/u3pmew
