In your last two paragraphs of your edit you seem to have sort of slipped in an assumption that our designs should be constrained to at least some extent by what we can teach new programmers in their first few weeks? OO can still be a helpful metaphor, while at the same time perhaps not being the very very first thing we should teach. For instance, perhaps we should not teach the solutions of OO until the student has gone far enough to encounter the problems it solves, to at least some minimal extent. (I include the question mark on purpose, I doubt this is exactly what you meant.)
As a bit of a sidebar, I'd also observe that the metaphor we ostensibly want to teach our newbies, about how objects are nouns and methods are verbs and it can model the physical world and lets go talk about class hierarchies involving animals and vehicles, has fallen out of favor in the more advanced OO circles anyhow, since it is, not to put too fine a point on it, a useless way to design real programs. This would also seem to suggest that perhaps OO isn't necessarily the best thing to go out of the gate with.
What prompted this wandering, incoherent mumble was wondering if "what we can teach new programmers" is somehow related to "what is readable by unskilled programmers new to our programs." If OO gets in the way of new programmers, I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them.
I don't really have a full conclusion, but if we grant that it is a useless metaphor, and just a tool for organizing programs, I wonder if it ought to be relegated to a corner of most languages rather than being put front and center.
I was wondering if it would get in the way of the mythical maintenance programmers trying to figure out what our programs do and how to modify them.
This seems to me to be the point at which your idea goes strange. Why assume that maintenance programmers are interchangeable monkey-cogs with minimal understanding of software development and design? Perhaps we'd have better software if we treated maintenance and ongoing development as tasks requiring just as much, if not more, talent and knowledge and skill and practice as green field development.
(I understand that soi disant architects might disagree, but I ignore architects who don't code.)
As a bit of a sidebar, I'd also observe that the metaphor we ostensibly want to teach our newbies, about how objects are nouns and methods are verbs and it can model the physical world and lets go talk about class hierarchies involving animals and vehicles, has fallen out of favor in the more advanced OO circles anyhow, since it is, not to put too fine a point on it, a useless way to design real programs. This would also seem to suggest that perhaps OO isn't necessarily the best thing to go out of the gate with.