I think you're right, except when it comes to what you say about brevity.
I don't think it's important for a program to have a small text-footprint in order for it to be easily loaded into your brain. Why? Because it's the CONCEPTS behind the application code we're loading into our heads. It's not the text itself. So... if I have a program where I've formulated a class tree, it doesn't matter to the ease with which I can grasp the program whether the classes are formulated in Python, C#, C++ or Pascal. It's the concept of the class tree which we load into our head. Not the code itself.
So, on that point you're actually wrong. Brevity isn't important.
That said, a lot of your other points actually DO make sense.
I'm pretty sure what you described is what he meant by brevity. It's not about writing less code per say. It's about adding layers of abstraction, which classes are, to shrink the problem space.
Comparing python to assembly, python has basically added in another level of abstraction. It's easier to translate a concept into python because of this. A good hacker can build up these abstractions himself no matter the language, but it's just easier and nicer to use a language that has the type of abstractions you'll be using already built in.
Once you fully trust your classes then they become like DSLs and you build your program out of them rather than the raw bits of whatever language you're using.
"... So, on that point you're actually wrong. Brevity isn't important. ..."
I don't think it as just brevity. I like to think of it as "high efficiency" in design, less moving, simpler parts. The less parts, the less the overheads in maintaining and understanding.
Having concepts of what happens is not the same as having actual understanding of what happens. So does this mean I ditch all my other tools and use say "lisp" exclusively for brevity's sake?
No, I make a pragmatic choice of python (or perl, php etc). I get similiar succinctness but access to tried and tested tools others have created. I don't want to re-invent web servers, databases or the RSS for instance.
This may be an advantage of design patterns: that they allow for a sort of brevity of class structure. You can think "ok, that's just the Composite Pattern there", and store it as one token in your short-term memory. Or at least fewer tokens. If your language let you, for example, use the Composite Pattern as a first class feature without having to code it every time, I'd bet your program would be easier to load into your head than one where you've got your own, new and possibly buggy, implementation of the pattern.
I don't think it's important for a program to have a small text-footprint in order for it to be easily loaded into your brain. Why? Because it's the CONCEPTS behind the application code we're loading into our heads. It's not the text itself. So... if I have a program where I've formulated a class tree, it doesn't matter to the ease with which I can grasp the program whether the classes are formulated in Python, C#, C++ or Pascal. It's the concept of the class tree which we load into our head. Not the code itself.
So, on that point you're actually wrong. Brevity isn't important.
That said, a lot of your other points actually DO make sense.