Definitely, good names are certainly worth an effort.
I doubt anyone here is really going to argue that Unity’s conventions through the years have been consistently good, but nor have they been consistently bad.
But when you have a growing product with which the team changes over time… things happen, bad choices are sometimes made. And once they’re made… well, it’s hard to change it without breaking backwards compatibility.
I guess that would also be too abstract, probably too far off and might raise multiple other questions and cause by far more confusion. But it’s good when one needs to describe what kind of objects they are. They’re standalone objects in that their sole existence is not dependent on any other type of object.
I doubt their intent was really to use the term “object” like we use to in software development. I think it’s more of a very abstract and conceptional term (what I referred to as “actual objects” earlier).
As for components, they are scripts, too, but when we think in pure components, e.g. a health component or a movement controller, these are not the typical “objects” one would conceptionally add to a game - it’s just the technical part, the way Unity was designed, the technical implementation if you will.
They also could have continued that rather weird convention and name it MonoAsset, MonoObject … with respect to the naming of MonoBehaviours. But that as well would have raised question and caused confusion… There’s no way out and it’s pretty much what @Kurt-Dekker said… technical naming is pretty difficult, especially when one develops SDKs/frameworks or an entire engine.
I have to admit, in my spare time I do lot’s of weird experiments focusing on code architecture, abstractions, patterns etc… sometimes I end up with such beasts, too. It’s fun though.
I don’t think you should be afraid of too long names though, with modern code completion. A descriptive name is always better than a none descriptive name with a comment that describes it, a comment that in time will desync with the code