When to use user entities in Dialog Flow?

In Where is the data context in Dialog Flow (API.ai) I asked how to keep user-specific data. For example, the user asks for a list of cities and the webhook service randomly picks three. If you then want to refer later to a city in this list, you somehow need to store it. The answer in the issue was that it could be transferred back and forth in the context.

Now I read about user entities in the documentation. This was an unknown concept to me. My question is now: could we also use user entities for such flow? For example:

User asks for 3 cities.
Webhook is called and 3 random cities are picked. At this moment, the webhook service also creates a user entity @user-cities for the ongoing session via the REST API. We could even have the SQL identifier as the key and the name of the city as a possible synonym.
In later intents, we refer to the @user-cities for a parameter. When a valid city, based on his previous list of cities, is provided to the webhook service, the identifier will be provided. The webhook service can then use this identifier to provide additional information about the city.

Example flow:

User:  Please provide me some interesting cities.
Agent: What about New York, Berlin and Barcelona?
User:  Please tell me more about Barcelona!
Agent: Sure, Barcelona is ...

I did not try this out yet, but I am wondering if this is a good applicaiton of user entities? The follow-up question would be: when would you use user entities and when would you keep the data in the context?

While this would work... sorta... it isn't really a good application of User Entities. The biggest issue is that you're now making an API call to create an alias for terms like "this" or "that" or "that first one". And you're constantly changing those entity definitions, including removing old aliases and setting new ones.

User Entities are best for things that you know about that user that will differ from other users. To use your cities as an example, you may use user entities to store a person's favorite cities or any nicknames they have for those cities. Once the user logs in, you'd then set @user_cities and their nicknames for a city are now available.

Update To use another example, again with your cities framework.

You might change a User Entity for features and aliases about a particular city once it is selected. So if the user selected "Sydney", you might create a @feature user entity containing entries for the opera house, or the beach, but not anything about a clock tower. While for "London" we might add entities about a tower and a bridge, but not a beach.

The focus is on what you want to hear from the user vs what you want to remember about the conversation.