Maybe we're getting into semantics, but you're listing the names of full software products or outward-facing open-source projects. The world is rarely coordinating to refactor responsibilities between different software products, since now you're talking about trading functionality across company / organization lines. At that level, I'd definitely agree that software is clearly a bazaar, and a whimsical, cryptic name is at its best.
"Software component" has the connotation, to me at least, of being an inward-facing _piece_ of one of these products. It is but one component of a system, and thus it is to be understood by its function within that system.
I think in many domains, the best advice is to name those components helpfully, and to think about the component's role in the system. To start adding functionality to the component outside the scope of its name is to invalidate your design. There is no reason to bloat this component. You'd rather create a new component to handle the previously overlooked role in the system. This is made obvious when you take limiting cases, like designing a moon lander. Here, the software design must be purposeful and optimized, and it only needs to work once. In the opposite case, the component is a web microservice - a living thing managed by a 1-pizza team that always needs to be turned on. Uptime and speed of implementation are at a premium, and creative ways to add new functionality on existing systems are seen as a net good. Here, the article's advice might be good.
Moon landers all get names. Even moon landers that never made it past the design phase probably had codenames.
You've stumbled on yet another situation where you should give something a cute name instead of a descriptive name: If there will be many implementations of the same thing over time. Each generation of Intel processor, each sort algorithm (TimSort, thanks Tim), each rocket, each mid-sized sedan.
Now, do the individual software components within a moon lander get names? That depends! Are they re-used between landers? Are there many different implementations of the same component to choose from for each mission? The more affirmative the answers to these questions, the more likely it is the component will have/should have an actual name, instead of just being, say, "allocator.c".
There are just so many reasons you might want something to have an actual name. Competing implementations or historical implementations, userbase size, project longevity, researchability. And they're all subject to change in the future (and renaming sucks). I have a hard time faulting anybody for giving their little binary data format a name like "parquet", even if it's tiny and only used in one place by one other thing and might never have any users. Because it might end up used for a long time, or by many people, or in a period of competition with another implementation of the same thing. If any of those things comes true, you're going to be glad you didn't name it "Hierarchical Data Format".
"Software component" has the connotation, to me at least, of being an inward-facing _piece_ of one of these products. It is but one component of a system, and thus it is to be understood by its function within that system.
I think in many domains, the best advice is to name those components helpfully, and to think about the component's role in the system. To start adding functionality to the component outside the scope of its name is to invalidate your design. There is no reason to bloat this component. You'd rather create a new component to handle the previously overlooked role in the system. This is made obvious when you take limiting cases, like designing a moon lander. Here, the software design must be purposeful and optimized, and it only needs to work once. In the opposite case, the component is a web microservice - a living thing managed by a 1-pizza team that always needs to be turned on. Uptime and speed of implementation are at a premium, and creative ways to add new functionality on existing systems are seen as a net good. Here, the article's advice might be good.