Without necessarily endorsing the article's ideas....I took this to be like the diamond-inheritance problem.
If service A feeds both B and C, and they both feed service D, then D can receive an incoherent view of what A did, because nothing forces B and C to keep their stories straight. But B and C can still both be following their own spec perfectly, so there's no bug in any single service. Now it's not clear whose job it is to fix things.
OOPs = "object-oriented programming", BUT it's a more restrained and thoughtful complaint than just "objects suck" or "inheritance sucks". He cabins it pretty clearly at 11:00 minutes in: "compile-time hierarchy of encapsulation that matches the domain model was a mistake"
I've seen a db mock work when 1) there was a small subteam in charge of the OR-mapping, schema structure, and included a DBA; and 2) also a design policy from the architect that all objects had to come out of factories. Under those specific circumstances, having the mock - used solely as a per-developer object cache imitating the factory interface - was critical for unblocking the people working on business logic and front-end.
I like this - nice playing around. We usually think of this kind of tree as having directed edges from parent to child, e.g. from set to element. In your graphs, you're erasing the direction of the edges, which uncovers a neat little symmetry that I never thought about before.
All the (non-limit) von Neumann ordinals are of the form X+1 = {X, {X}}, where X is the previous ordinal in the set. If you just look at trees of this form:
X+1: X <- node -> {X}, or X <- node -> node -> X
then you ignore the direction of the parent-child relation, you get this:
X+1: X -- node -- node -- X
So that's why your trees are symmetric as undirected graphs; and of course, every lower ordinal has its own version of this symmetry, which is also contained in the tree. All the large gaps between sections correspond to node--node edges of the larger ordinals. Kinda neat!