There is a downside to not naming things: All the concepts are in your heads and not in the code. It's not self-documenting at all. No one names that div or section or whatever tag via a readable class name, so any future reader will not know, that that might be a concept bound thing in the site. Styles are just applied until it works, which leads to a mess. New web dev comes in and gets told "That font is too big!". New dev opens the inspector, looks at HTML element soup. Hurries to the code, replaces some styling on that level of nesting in the HTML, but does not understand the concepts of the site at all, nor that there are probably 10 other places, that now need change.
A well thought out class name would have helped understand, that new dev is actuall editing something, that is part of a group of things, which all have something in common.
Naming things is hard, but finding good names is worth gold. Avoiding the hard parts is not going to be the solution to all problems. We would all be working in some kind of modern version of lambda calculus, if naming wasn't important. There are good reasons, why we name things. To convey meaning and convention. Not naming things hides these and makes them implicit, instead of explicit.
There is a line to be drawn somewhere. If you set your naming level too high, then it's not clear what you're doing in the details. If your naming level is too granular, then you start to lose clarity because you can't see the wood for the trees.
Regarding the problem of a developer new to the codebase being told to change the text size in a specific place; Tailwind works well in this specific situation.
At the beginning of your project, you will have chosen a (or accepted the default) text size scale. The new developer will probably choose the next largest step in the scale and step back. The new size will be in harmony with the rest of the project because it matches the scale. If this specific element is repeated elsewhere in the project, then it will be part of a component and all instances of that component will receive the change.
The right place for a considered name in this example is at the component level.
A well thought out class name would have helped understand, that new dev is actuall editing something, that is part of a group of things, which all have something in common.
Naming things is hard, but finding good names is worth gold. Avoiding the hard parts is not going to be the solution to all problems. We would all be working in some kind of modern version of lambda calculus, if naming wasn't important. There are good reasons, why we name things. To convey meaning and convention. Not naming things hides these and makes them implicit, instead of explicit.