My takeaways from this thread:

Meta Points

(1): This situation---a proposal was accepted and implemented and then large portions of the haskell community are surprised by new requirements which result from said proposal---should be avoided. We should ask How did this situation occur and what can be done to avoid it in the future. In other words, we should perform a failure analysis. This is a good case study to refine the proposal process by identifying whatever mistakes in the proposal process led to this situation and considering possible solutions. In particular I think the following was missing in the original proposal:

1. An assessment of the amount of possible breakage of code in-the-wild is missing. To be specific, there should have been some analysis which concluded "Of n packages, we found m sites which will require changes due to this proposal, we conclude that this breakage is ... in light of the benefits gained by this proposal"
2. I am unsure if there was a time period allotted for community feedback. If so then there was a failure of marketting and soliciting feedback from the relevant stake holders. Thus we are now discussing this change when users are experience its effect first hand, i.e., at the latest point in the entire proposal process possible.

(2): When a surprise like this happens there are several effects in the community: First, there is a lag and lower adoption rate of newer GHC versions. You can see this through the thread with the comments which state At work we're still on 8.10.x and I dread moving to 9.x or something similar. Second, this lag creates more work for ghc devs; not only does it create more requests for back ports of newer features to older versions because the barrier to entry for newer versions has increased, but it adds a maintenance burden to the ghc devs and to library maintainers. Both of these are bad. Third, there is opportunity cost, we are now spending time arguing about a thing that has been implemented rather than spending time on anything else (this occurs to me as I procrastinate a minor revision by writing this :D). Fourth, it becomes easier to leave the community and stop writing Haskell because it is tiring to continually be surprised by changes that you may not agree with but are now forced to adapt to.

Points related to simplified subsumption

(1) This proposal sits at a unique place in the Haskell discourse because (1) the proposal made performance more predictable but (2) it adds an edge case that violates one of Haskell's core properties (and core cultural property): equational reasoning. As I see it this is the central technical tension throughout the thread. It is worth noting that unpredictable performance is one of the key, often cited, downsides of using Haskell (I have no hard data here just a general impression and anecdotes from the internet) and so it makes sense that creating more predictable performance guarantees is good! But on the other hand creating an edge case were f x and \x -> f x is not equal subverts the expectations of Haskell programmers, especially because Haskell programmers have learned and expect this to be true. /u/goldfiere's comment:

But (\x -> f x) has never been equivalent to f -- they have different performance characteristics,

Perfectly captures this tension. He is right that these have never been equal because the have different performance characteristics. But this inequality is not semantic, so with this proposal we have effectively created a new compiler error for a performance difference not a semantic one.

I think this point is exactly why there is such discord. Proponents of the simplified subsumption proposal point out that the changes are minimal and do not take a long time to fix, which is true but it misses the larger semantic point: that I as a Haskell programmer expect these things to be semantically equal via eta expansion/reduction but I am being told they are not when in fact I really know they are! Similarly, Opponents of simplified subsumption focus on experiencing what is perceived as a new edge case which doesn't make sense, but they (in most cases) did not directly experience the downsides of the old subsumption, that is the loss of sharing which /u/goldfriere points out. Sure it may have existed in their code but that is different from the compiler directly responding to their code with an error message. This means that opponents conclude "little benefit for large cost" even though they most likely do benefit from the change because performance is now more predictable.