It's amazing to me how even smart people can be taken in by Harold Hill types. Can I get a job going around giving advice for $100k a pop? I promise to do better than that guy haha.
The team treated that as puzzle-solving, and it was part of their culture to tackle those kinds of challenges. There was light hazing of newbies whenever the CI didn't pass because methods were too big. So, that's why at least in this case. There was no technical argument, just inertia.
Code quality was atrocious. Things that could be 10 lines were 30 or 40, and extremely stateful.
Ousterhout is saying that we really want deep classes, i.e. the complexity of the implementation a construct hides should be considerably larger than the complexity it takes to use it. Which, at least to me, basically says "search for good abstractions". And what you're describing strikes me as a good way not to achieve that.
Of course, there's considerable wiggle room in that mental model, and one could still endlessly squabble about how (not) to break up the implementation.
[1]: https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
I think the fallacy of the "Poltergeist Pattern" is to optimize solely on the - in itself valuable - metric of short simple methods, without consider anything else, like the complexity of using or reading the resulting code.
Tons of tiny functions, each doing almost nothing, frantically calling each other, and somehow useful functionality results.
Each function is very easy to understand, but how they together do useful tasks is near incomprehensible.