I make a distinction between metaphors and Metaphor Systems𓇯. Metaphor systems (like `Love Is a Journey`) operate at the so-called "basic level" of categorization. Metaphors are more concrete. Programmatic metaphors are generally at that more concrete level. Thus, I argue, program names don't have the "oomph" to serve as Conceptual Metaphors𓇯.
content
Consider an animal on the street. You could call it a "dog" or a "mammal" or a "Schnauzer." How abstract do you want to be?
Perhaps 70% of the time, perhaps more, the choice will be at an intermediate level of abstraction, the so-called *basic level*. In this case, that would be "dog." See Properties of the Basic Level.
I'll call all categories more detailed and less abstract than the basic level the Concrete Levels.
Categories more abstract are Abstract Levels.
Most of the Source Domains𓇯 in Conceptual Metaphor𓇯 are at the basic level. Consider `X Is a Building` or `X Is a Journey`. "Building" and "Journey" allow a lot of variation, akin to "dog." But they're not as unspecific as "Physical Building" or "Activity". So: basic level. (Objection: Basic Level or Higher?)
When metaphor systems are used to generate specific metaphors, like "our marriage is at a crossroads", the concepts drop down to a more concrete level. The metaphorical image provides a lot of details not present in "Journey." For example, "crossroads" brings up the idea of paved streets (more specific) and, at least to me, a vague mental image of being in an automobile.
The important thing here is that setting the metaphor system at the basic level gives you as a speaker a vast number of possibilities to choose from to highlight what you want to "get across." Conduit Metaphor𓍯.
**Data structure names are not like that**. If you name a class `User`, creating a new instance doesn't give you an opportunity to add new details that increase someone's understanding of their situation. (Someone? Who? The program itself? Later programmers reading the code?) That's not what `u = new User()` is *about*.
**But**...
You could argue that making a subclass `Administrator` of `User` is like going from a Metaphor System𓇯 to a metaphorical utterance.
I'd say the difference is that an utterance is a different kind of thing than the `X Is a Y` system it's derived from. (In Smalltalk terms, both `User` and `Administrator` are instances of `class Class 
`.)
Moreover, Real Metaphors Are Promiscuously Mixed𓅮. They are used to draw attention to various different aspects of the problem or conversational topic at hand. This is different than using a metaphor system in that you're definitely not wanting to bring *all* the associations to mind, just a few selected ones. With a class (or an instance), you get them all without any obvious way to know which are relevant to the code at hand.
**But...**
You could imagine a metaphorical utterance as creating an on-the-fly interface (or subclass) specifically tailored to expose only the properties and methods appropriate to the code at hand.
Maybe, but nobody does that.