YOUTUBE yBEcq23OgB4 Kent Beck talks at DDD Europe 2023
Two elements can be coupled with respect to some changes but decoupled with respect to others. If you have a function which calls another, they're coupled with respect to name changes. But they're not coupled with formatting changes or private method changes. A static analysis of coupling makes no sense because it depends on the your changes. 25:19 
An important nuance of coupling is that your tools have a part to play in how parts are coupled. Automated refactorings reduce the coupling of elements because a change can be made in a single atomic activity. 29:57
The span of coupling is important to look at, and Structured Design calls this Cohesion. An element is cohesive if it's sub-elements are coupled. SRP is the stick you use to hit other people with. 32:12
You can reduce the cost of making changes by reducing the distance between coupling to the same locality. 40:26
One of the challenging aspects of software design is there are two audiences about writing for software design. There are lumpers, and splitters. 41:24
Behaviour changes are visible, go on the roadmap and have obvious economic impact. Changes to structure change optionality which makes change cheaper, easier, or safer. Optionality is harder to account for than revenue so we underinvest in structure and overinvest in behaviour. We have fewer behaviour changes than we could have gotten if we'd balanced the investment both ways. 49:49
When experts approach a problem they separate it into subproblems that can be addressed with ordinary levels of skill. Decomposition may take creativity. Good programmers separate behaviour and structural changes, and that's how you take the next level up in complexity. 54:11
DDD has tools to do complexity partitioning called bounded contexts. Inside of a context, I have some level of knowledge and ignore outside of that. 55:08