the title is a little hyperbolic, but the article does a good job of presenting how to use backpack, i however think that it is missing comparisons between backpack signatures and typeclasses to support its claim that backpack can do the job of typeclasses.
for one how would you implement a Van Larhooven lens type with backpack signature
Lens s t a b = forall f. Functor f => (a → f b) → s → f t
and in general RankN types doesn’t compose with backpack
strawman 
The post isn’t about backpack, it says in the post as well.
Even if it were, it doesn’t advocate replacing all typeclasses or all their functionality (wouldn’t you get typeclasses if you did that anyway? The strawman is a bit silly).
Can we please keep such violent language/imagery out of the forum – even in jest. I’d prefer the community to be a place of welcome and life-affirming. I aspire to engage in open exchange of opinions without wishing death on anyone or anything.
no, keeping death out of the forum is beyond my capabilities.
I recommend taking a look at Edward Z. Yang’s thesis linked in the post, it’s quite readable.
One of the original motivations for Backpack back in the day was to solve the perennial “string problem”, but the attempt didn’t pan out. Although it could make sense for some libraries today to depend on an abstract string signature and provide several secondary libraries with possible implementations. With the current improved support for secondary libraries in Hackage, it would be less inconvenient than it was before. But most libraries go with a typeclass approach because it’s the most familiar one.