This is part of the reason why I like Tailwind-style utility classes and Typescript union/intersection types. The simple fact that I am (often) spared the intellectual effort of coming up with a name. I wrote this: https://itnext.io/and-naming-things-tailwind-css-typescript-...
For limited occurrences that’s correct, but if you find yourself having the same `foo | bar | baz` all over the code, you’re going to want to introduce a shortcut term for it. Even just to be able to efficiently talk about it.
The other thing is that unions/intersections are not an abstraction, because they don’t hide any details. The purpose of an abstraction is to separate essential properties of whatever is being modeled (the interface) from current details that may change later, or that client code shouldn’t depend on (the implementation).
In case it's unclear, I agree with you completely. Introducing the right abstraction into a code base can feel like someone switching on the lights. Far more benefit than just DRY.
Conversely, I am currently working with a frontend code base that is using "classic CSS", and it's striking to me how frustrating it is to have to think up what the "semantics" of this and that particular <div> can be said to be, when there very often aren't any.
Yes, one of the reasons I like using mypy for python and typescript for frontend is that it forces me to recognise opportunities for abstractions. If some input/return type is getting really complicated or reappears in many places in the code then likely it’s a good candidate for an abstraction.
