I think the problem is actually deeper than the observation here. The core problem is that software engineering is still very immature. We simply lack a common technical vocabulary of robust and well worn models and generalized systems and their most salient attributes. That lack of being able to describe and understand the operation of components without disclosing the mechanism of their internal operation leads to "black boxes" being blacker than they should be. And that in turn leads to people using components in ways that aren't applicable, because the abstraction was too crude. It doesn't require knowing how a flourescent lamp works to know that they're not well suited to say high intensity search lights, or strobe lights. Software uses can encompass changes of many orders of magnitude, for example, but often the scalability of components is not even part of the vocabulary. Often the naive conceptualization is that a given component is usable in every possible context. This idea is patently ridiculous, but we lack the terminology to move far beyond that. Imagine if people thought that merely because some company made A car that you could use that car for everything automobile related: commuting, cross-country rally races, lunar roving, towing tractor trailers, etc. That's the level of sophistication of abstraction models we are at today.
The observation in the OP is quite deep, and certainly addresses all of the points you are making. And it's not a problem of terminology, it's a problem of design. What Kiczales is talking about is the power of descriptions such as this:
There is no black box here as there is no implementation. We haven't committed to any specific misconception an implementation might represent and we've left the door open for massive scale.