Very cool explanation Hodgman,
For the OOP/OOD debacle I think it is because I have seen much bad OOP code in production systems (I have had my own company since 2006, but admittedly I always have a strong bond to academics, I want to improve scientific data visualisation) and with lots of zealots marrying themselves to concepts that you say (inheritance for re-use, coupling, over-use of templates etc.) where they are "experts" but only experts in making the code more bloated, harder to understand and hard to extend.
I've seen this so many times in companies that I think it boiled down to the fact that the designer wanted to have job security by designing something overly complex and that management would never dare to touch. I have also been part of such management and seen it pushed on me.
I have always pushed for independent code blocks, modules and as much as possible data oriented programming not because it gives better performance (but sometimes does, in fact most of the time does as access is often linear and sequential (but that is another discussion)) but because it it allows for clean decoupling almost treating the code as some kind of scripting language doing transformations on data.
So yeah, when I see clean OOP code I am more than often surprised and it is mostly because the person has gone though the zealot years of OOD (what you call badly taught OOD and I agree, just that it is so dominant right now it is hard to say what is good OOD) then came out "cleansed" of such over complicated notions and has a better flexibility with design and thinking about programming.
I have a much easier time thinking of someone with a background with a function based (not functional lambda calculus) experience like C/Pascal will do a better job at designing software than someone with a (bad) OOD background. He or she would use the modules approach of Pascal and apply it to OOP and we would all be happier for it.
I am always trying to improve and to know more about OOD (a new improved way) is always interesting.