I think he is right.
I was objecting to the way he argues his point, not to the point itself. There isn't much room for discussion if the opposite side is "delusional" or a "case for the mental institution".
Programming should strive for simplicity. The more you must explain, the less obvious it is.
And the way type classes work right now is rather simple. You could make them take a type lambda or something like that, to point the type argument that is meant to be modified, and perhaps treating tuples like two-element containers could somehow work. But instead they work in a simplistic, but predictable way. The intuition developed for tuples is applicable to any other type in Haskell. Complicated manipulations of data types can be handled with lenses, which compensate by allowing less polymorphism, so that the overall complexity doesn't blow up. Heterogeneous containers are provided by packages like HList or Vinyl, with their own tradeoffs. Etc, etc.
You can write programs with unintuitive behavior and document that intensively, but it won't fix the missing intuition.
As I see it, programming is a discipline of engineering, not humanities. All things being equal, it's better to have things behave in a familiar way, but if a different behavior naturally follows from the formal system underlying the language, then too bad for these arbitrary notions of "common sense". Stripping corner cases (like Functor or Foldable instances for tuples) or making them behave differently for the sake of intuition, actually adds complexity to the language while removing functionality, in my opinion. I think it's like arguing for removal of complex numbers and matrices from mathematics because their arithmetic is confusing. Best regards, Marcin Mrotek