I can be dismissive of webdevs myself but this comment is too bitter for my taste. It sounds like you learned the salary of your greenhorn webdev nephew recently.
The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and just backronym it). This isn't a new idea. Lots of greybeards know this and name stuff accordingly.
It's _A_ truth, but it's a truth that is inextricably intertwined with a certain context. If your software components are services running in the backend of a large web service company, then their purpose is likely to mutate as time goes on. In that paradigm, I totally believe it tends to be true that you're better off giving up from the beginning and just choosing unique names from the get-go. Your system is more like an ecosystem of organisms that will grow and adapt.
But in OTHER contexts, your software components might be more like organs. If the heart has also become responsible for digestion, then it indicates your system design needs to be revisited. In lots of software projects, this is not an untenable proposition, such as it presumably is in a web service company.
As somebody who works in one of those other contexts, it's important to me that the web service monoculture be correctly contextualized. Otherwise you have people cargo culting it in situations where the wisdom no longer applies. That's probably why I'm being so bitter. :(
I'm saying it's not just webservice monoculture. It predates the web. Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git?
If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothing web-development-specific about that. Big projects get Name-names, like companies or people. Always have.
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".
The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and just backronym it). This isn't a new idea. Lots of greybeards know this and name stuff accordingly.