However, I think there is something to the article as applied to the software industry. Often times we have come to understand solely through abstractions and abstractions are dangerous in this regard particularly when they don't match reality.
A really good example of this was the effort to apply the OSI model of abstractions to TCP/IP back around the turn of the century. Without an understanding of what made the ITU OSI effort different from the DARPA TCP/IP effort, at best one got an overly confusing and misleading understanding of what was actually happening from a networking perspective.
I do a lot of teaching these days as I have changed from being a self-employed consultant to being an employee at a Swedish consulting and training firm, and I do a lot of thinking as to "what are the right abstractions to push in this course?" In IT, that is a remarkably difficult question and one I answer largely through my love of history. For example, when I talk about object-orientation, I start with procedural programming, discuss why structural programming largely replaced it, and then discuss the problems of having your code contracts based on your data structures in C. From there I go to my main abstraction: Object orientation is an effort to hide state changes behind interfaces, to make the interface responsible for the state rather than the outside routine responsible for it. (This also makes it easy to start discussing functional programming.)
The danger of the expert is that the expert may become complacent about this question but the best experts are those who have not. Feynman wrote about insisting that he could explain his theories to his non-physicist relatives. Heisenberg wrote a book on the history of philosophy and how this applies to physics arguing the whole time that data does not imply theory.
If our experts aren't good teachers, that says more about what we want from experts and about our industry than it does about expertise generally.