There's an easy way to approach
user-select: none, and that is to ask a single question:
Would selecting the text be the primary/secondary interaction a user would intend if touching the screen there, or would it be a hindrance to the task they were trying to carry out?
Image Carousels (love them or hate them) are a fantastic example of this. In a touch interface, what do you—as someone trying to interact with the carousel—want to happen when you press your finger down above one and then slide to the right or left? Do you want the carousel to rotate, or do you want to be selecting the image under your finger?
If an individual carousel image element gets selected by accident while scrolling, can you even deselect it, or are you now presented with a selected element that may do something else if you try tapping it to deselect it (such as page navigation, if the
img element is encased in an
a element)? Or, depending on the arrangement of divs that makeup the carousel's structure, did you now just somehow select a higher layer that's leaving a selection highlight across each image? (I've seen all of these happen in poorly coded carousel implementations)
Generally speaking, this is a case where you want the presented set of objects to work as a navigation control (sliding list of images) and if the browser interpreted the touch as a selection command it would interfere with that role and make interacting with your control frustrating.
The goal in employing
user-select: none should always be limited to reducing user frustration from unintended selections resulting from interaction that can easily cause them when attempting to carry out the primary task purpose of a control it is used on.
"What about protecting my content from people who will copy it by selecting it!?" you may be inclined to ask. The answer to that will always be: no. Not only is that poor UX, but it is also absurdly pointless. Anyone who truly wishes to copy your content still has access to it; you've just made it more frustrating to get to, which will make them less inclined to care about whether what they are doing is ethical: you're essentially promoting moral disengagement and allowing their evaluation schema to balance their normal ethics schemas against their frustration with you, reducing the threshold of cognitive dissonance in self justifying an act like copying your content.
user:select none is never a security factor. Never use it expecting to achieve any higher level of security from copyright infringement/etc. Your content is still right there in the source (and is still easy enough to take screenshots of, which would be even harder for you to find if you were trying to trace infringement).
You should never use
user-select: none to prevent selection of content text. The browser itself is responsible for deciding between scrolling and selection in this case and should be relied upon to do its job properly in discerning user intent between the two potential actions (selection or scrolling). While there will always be exceptions, keep in mind that these two actions are globally consistent expected interactions. Interfering with them will likely lead to your application not behaving in a manner that is expected, which is a primary source of frustration.
Personally, I would say you are on the right track with your example uses.
I would only caution that
user-select: none is a very blunt edged instrument to be employed only based on definite need. While it can add polish, be careful that you aren't using it someplace where from your context selecting seems pointless, but which might actually be something a person using your application would want to be able to select for a given reason, and where being able to select it won't otherwise interfere severely with the intended interaction in attempting to carry out the primary task the control exposes.
A good example of this is modal error dialogs. It might be tempting to make them non-selectable so that any interaction removes them, or some similar rationale for what's intended to be a streamlined experience of some sort, but this can be hugely frustrating if someone is faced with an error and wants to look it up or report it to support, but can't easily copy it to do so. Always err on the side of caution and a light touch when affecting and especially when removing standard provided modes of interaction within a given environment.
In general, I would say that any time something is (or includes) informative content—like the error message example—rather than a control action that contains no new information, it in nearly all cases should not have
user-select: none applied to it. This is especially true when that content is not presented in a selectable form elsewhere on the same or a tightly related screen. There will always be exceptions, but I would caution that it is generally better to re-evaluate how you are implementing something and finding a different method of control than it is to apply
user-select: none where content is presented instead of simply action words/generic terms/etc.
Some people would argue that (some) mobile applications have removed the degree to which this is a standard interaction. I would say that within the broader, most global context it is still a standard interaction and many of those applications have likely degraded their user experience by doing so, or have simply been sloppy in their programming by not providing the ability to make selections (as is sometimes the case, instead of specifically disabling them).
Particularly when we are presenting an application through a different agent (such as a web browser) it is important to let the user agent preserve its own methods of content interaction as much as possible. Not only does this increase conformity and consistency in the user experience, but it also heightens cross platform/agent compatibility, and even helps ensure future proofing and functionality across use cases or environments you may not have personally foreseen.