That’s why I think it’s an interesting part of the conversation 
I don’t believe Ousterhout is against having (e.g.) small methods. However, he is saying that if you’re going to introduce a new method/class, make sure it will be reducing the overall complexity of the system or that change will be a net loss.
In other words, he advocates making things modular as a way to reduce complexity in our software designs, instead of as a goal in itself. One of his reasons to not blindly follow “functions can only have X lines”-type rules is that by doing so without critical thinking you’re just exchanging complexity within the method (assuming shorter methods are simpler to understand) with complexity in a higher level (because now you need to know a new function signature, a possibly how it is implemented). Kind of like what Rich Hickey means when talking about “guard rail programming” (about 16 mins in): adhering to these rules doesn’t absolve you of thinking about how best to design your software. I.e. your software can still be poorly designed even if you’ve religiously followed all “rules”.
Fundamentally, one of Ousterhout’s points is that if to understand what a function is doing you need to look at the implementation of the functions it calls, you may want to reevaluate splitting out those functions. Because if you need to know about the implementation of sub-functions to understand the main function, you’re not abstracting away anything at all: you’re just adding extra steps to understanding the code (via jumping around to sub-function definitions). In those cases, he says, it might be better to have (some of) those functions inline within the main function, so that everything you need to understand what’s happening is available where it needs to be understood (with the relevant context).
