Naming things is half of engineering
Why a clear name saves more time than a clever feature.
Naming things is half of engineering because a badly named part, file, or feature costs real time from everyone who encounters it after the person who created it, while a clearly named one costs nothing beyond the small extra care of choosing a name that says what the thing in front of the reader is. A model built from beautifully engineered features sitting inside a file called simply "part3", or a feature called "extrude2", has hidden its own quality behind a name that tells the next reader nothing, and the next reader is very often the same person, weeks later, having forgotten exactly what they meant.
Every search starts from a name
A name is the only information a person has before they have opened anything, and in a large project almost every decision about where to look starts from a name. Deciding whether "bracket_v2" is the current version or an abandoned attempt, working out whether "hole_pattern" refers to the four mounting holes or the six ventilation slots, or figuring out which of three files called "final" was actually released to the shop floor, are all decisions made from the name alone, because opening every candidate to check is exactly the cost a good name exists to avoid. A vague name never fails loudly the way a broken feature does. It fails quietly, every time somebody has to guess, open the wrong thing, close it and try again, and that quiet failure repeats for as long as the name is left uncorrected.
This is why naming is so easy to underrate while a project is small. With three files on a desktop, a name like "bracket" is unambiguous simply because there is nothing else it could be confused with, and the cost of a lazy name stays close to zero for as long as that remains true. The cost appears once a second bracket, a revised bracket, or a bracket borrowed from an earlier project arrives alongside the first. At that point the name that felt perfectly adequate on day one turns out to have been depending on there only ever being one thing it could refer to, an assumption nobody stated out loud and nothing in the file ever recorded.
A ribbon on an identical black suitcase
A row of identical black suitcases circling an airport carousel are indistinguishable from a distance, and picking the wrong one, carrying it halfway to the exit before noticing, is a familiar enough error that many travellers tie a bright ribbon to the handle or clip on a name tag to prevent it. The same clothes are packed inside either way. All the ribbon adds is how quickly and confidently the case can be picked out from a crowd of otherwise identical ones.
A part or file with a vague name is the unribboned suitcase, correct in every respect except that nothing distinguishes it from its neighbours at the one moment that matters, when somebody has to choose the right one quickly and without opening it first. The traveller who ties the ribbon on at home spends a few seconds; the one who skips it may spend a quarter of an hour at the carousel checking luggage tags, and the same trade plays out in a project folder.
A minute on day one, an afternoon later
Renaming a part after a dozen other files, drawings and purchase orders have come to depend on its old name can cost an afternoon spent tracking down and updating every one of those dependents. The same clear name would have cost a minute or two when the part was first created, before anything else in the project had a reason to reference it. An afternoon is a couple of hundred times longer than a minute, and the gap only widens as a project matures and more things come to depend on the name already chosen. The best moment to fix a bad name is therefore always the earliest one, however small the cost feels at the time compared with getting on with the actual design.
Names that describe purpose
Treating a name as a small piece of design work in its own right, worth a moment's thought about what a stranger encountering it cold would need to know, changes what gets typed into that box. A hole described by what it is for, "mounting hole for the sensor bracket", survives every later change to the part's shape far better than one described by what it currently looks like, "hole1". The stated purpose stays true long after the geometry around it has been redrawn again and again, while a name built from current appearance goes stale the moment that appearance changes and nobody remembers to update it.
The same discipline applied to file names, feature names and folder structures compounds across a project the way a single clear label compounds across a whole shelf of otherwise identical boxes, each correctly named item saving a little guessing every time anyone has to find it again. A project with that discipline applied consistently becomes navigable by someone who joined it yesterday, where one without it stays legible only to the person who built it, and only while their memory lasts.
Which names are worth the care
Naming discipline has a cost of its own once it is pushed past the point of being useful. A project where every trivial fillet and chamfer has been individually renamed with a full descriptive sentence spends real time on names that were never going to be searched for or referenced, since a decorative edge break rarely needs to be found again by name.
The judgement worth developing is recognising which names will be read by someone else under time pressure (a top-level part number, a released drawing, a shared file) and reserving the careful naming for exactly those. Minor, disposable features can keep whatever short label the software assigned automatically, since no amount of care spent there would ever be repaid by a reader who was never going to look.