I think this is very dependent on many factors...
I don't allow most people to create "permanent" segments / C into our components lists; most people in our org can only create adhoc segments and calculated metrics; so that we don't clog up our reusable components.
And I've also made sure that unless there is a valid reason to have segments or calculated metrics as permanent reusable items, that people with the access to save as permanent component items are still to create as adhoc.
This of course means that most items I don't have to worry to much about naming conventions....
But for items that are permanent, we have a more simplified approach....
(I should start with explaining we have a different profile types, most of our sites are News, and are on the global suite, but we have other items like Auto Selling/Reviews, Business Directory, etc)
Segments are always prefixed with the type, so that we can tell which profile it belongs to ("News: " or "Directory: ", etc)
Calculated Metrics... if these are using standard metrics that could apply to any site; have no prefix, and if they are specific to the custom metrics in a profile, then it should be prefixed as above.
After that, I just ask that the name represent in the most readable way that people can properly identify what is happening... if the calculated metric cannot be clearly understood in a short name what it's doing (i.e. PV/V or Meter Stop Rate, etc), then it's likely not a good candidate for a permanent component...
Same with the segments, if the segment is too specific to a particular report, it should not be created as a permanent component.
If it's not permanent, then I don't care too much about the naming, just so long as it makes enough sense within the report, and if the segment requires additional information to give context, then add it into a text block or into the panel/visualization description.
I don't see any reason to add user initials into the name of either segments or components... the owner of the component is readily available; there's no need as far as I am concerned to show that in the reports that people are using...
I do however also ensure that all permanent components have proper descriptions and tagging so that people using them can read a longer specific description about their purpose and potential uses, and the tags allow them to be found easier by additional criteria.
But what works for me may not work for you.... 🙂
My best advice it to work with your team to understand what they may want/need in naming conventions and work to make sure that you can come to a consolidated decision that works for everyone.