We're talking about software service and component names. Not names in general or company names.
When my company got acquired, they rebranded our C++ library, but to this day the old software name persists in the namespace it uses because they weren’t willing to break every customer’s code. The name of the software can become part of the API in lots of ways (URL component, C++ or Java or other namespace, executable file name for scripting, etc.).
So yes, software service and component names are hard to change when customers start relying on them.
The author's argument is that large software components tend to shift in scope over time, so a very concrete name will become incorrect as the scope starts to misalign with the name. A hard-to-change concrete name at that point becomes a misnomer, and it would be better to have had the abstract name from the beginning. I'm resisting the word "cute" because I don't think that's really the core here -- the question is if names should be abstract or concrete, and the abstract names can be whatever aesthetic you want.
Why not use abstract names at smaller scales? I can come up with a couple of reasons:
First, smaller-scale constructs are easier to predict. The project as a whole might go in a ton of different directions and get pressed into service for a ton of different tasks. But my encodeBase64 function will only ever do one thing, and I can predict that pretty reliably, so I can give it a concrete name. I hope to someday find a codebase where every function is like this ;).
Second, smaller-scale constructs often have names that are easier to change. Most functions you write don't end up as part of some API, and the ones that don't can be given specific names with the understanding that it's easy to change them later if you have to. Obviously, this doesn't always apply.
Third, smaller-scale constructs suffer from less scope drift. I find that the pressures to change scopes are generally on the project as a whole, and a large part of extending a system well is to adapt the project as a whole to those pressures while protecting each individual component from them as much as possible. If you can do this well, each small component gets to be more stable than the project as a whole and can support a more concrete name.
Finally, maybe you should sometimes! Maybe you have a function that has had massive scope drift such that the name no longer applies. It started life as updateCustomerBalance, but now it's reaching into the supplier database too, and appending to a financial report, and hitting some backend servers at one of your vendors. The name is now actually misleading. (Ideally we'd refactor, but this article is just about naming.) It might be better with a highly abstract name -- if you don't like the cute route, something like executeBusinessLogic is abstract in the same way. It might be more honest than the specific-but-wrong name.
The name gets repeated in so many places if it's important. Documentation, code, URLs, databases--even just finding all the places you need to change it involves a ton of work.
like the parent points out, the named thing is likely "important" precisely because it had a non-descriptive name to begin with and engineers added things to it they shouldn't have
if it had a descriptive name then other functionality would've been put in their own module