Thanks for writing this up!
I was a user of SafeHaskell briefly in 2011-2012, and it certainly has theoretical benefits. That said, though, I agree that the balance of the cost-benefit analysis is solidly against it, and I would much rather ease the burden of GHC and library development than continue to maintain a burdensome niche feature with limited users.
That said, I think some of the comments in this thread are unnecessarily dismissive of SafeHaskell's usefulness and correctness. So here are a few things worth keeping in mind:
1. The strict type safety aspect of SafeHaskell is, in fact, the mechanism that makes SafeHaskell effective at controlling effects through limited IO access. You simply cannot have the latter without the former. Generalized newtype deriving, for example, is incompatible with SafeHaskell precisely because it can be used to break restricted IO access. It looks like a lot of the responses here ignore that SafeHaskell did a lot of work to make runtime-cost-free safe execution reliable, then make hand-wavy references to other systems that don't do any of that, and use that as a basis for asserting distrust in SafeHaskell. That's entirely unfair.
2. The assertion that safety in SafeHaskell depends on the correctness of a bunch of libraries assertions about their safety reveals a fundamental lack of understanding of how SafeHaskell works. Safety is inferred compositionally from the source code and the safety of the modules it uses, and a source code annotation about safety can never compromise the safety guarantees of SafeHaskell. The only thing that can compromise safety is a misplaced trust decision. Trust decisions are not in the source code at all. They are made outside the source by running `ghc-pkg trust`.
This conversation reminds me of a parable I encountered somewhere, in which someone declares "I don't understand why this decision was ever made, and I we should change it", and someone responds, "No, if you don't understand the decision was made, then you don't know enough to change it. If you learn why it was decided that way in the first place, then you will have the understanding to decide whether to change it." Just like in the parable, I am not disagreeing with the idea of deprecating SafeHaskell, but I am skeptical that the decision should be made on the basis of misrepresentations and crude analogies that completely miss what's unique and interesting about SafeHaskell in the first place.