Certainly a very novel (to me) definition of coupling and cohesion - I had to re-read the coupling section again, and I'm still not confident that I've fully understood it.
I may have misunderstood, but I think its lacking the idea that change doesn't necessarily propagate in both directions between two coupled elements. Taking the wire protocol example from the article, you can change one endpoint without that change propagating to the other, so long as you don't change the protocol element which connects the two endpoints. This then highlights the need for good abstractions and interfaces to break up the consequences of making changes.
I like the article because next time I have to explain to my manager why we should 'zig' instead of 'zag', I can explain the cost of hasty or poor code design in terms she understands (the long-term cost and pain).
It's nice to see some acknowledgement (and reasoned argument) that smaller isn't always better because there is increased complexity in the connections between parts of the system. I'm fed up of people who've read no research and learned their skills from Dogma University telling me or my team that we should be using smaller functions and fewer levels of nesting and trivially simple classes, because.
I may have misunderstood, but I think its lacking the idea that change doesn't necessarily propagate in both directions between two coupled elements. Taking the wire protocol example from the article, you can change one endpoint without that change propagating to the other, so long as you don't change the protocol element which connects the two endpoints. This then highlights the need for good abstractions and interfaces to break up the consequences of making changes.