The level of container that you use in a segment (hit/visit/visitor) is dependent on where you want to look for the conditions and what information you want to return. It isn't dependent on the persistence settings of evars. Although I will mention, if you have an evar and you want to make sure that your segment is capturing the hit where it fired and not hits where it persisted, you can bring in the "instances" metric for that evar, as the instances only fires when the evar actually fires on your site. But you can technically use any component with any level segment.
For example, say you want to return revenue associated with a group of products. You would make a hit level segment for those products and then apply the revenue metric. This would return revenue for any hit that has one of those products in it. You could also add the 'orders' metric to make sure that it's limited to hits where an order exists, although if you're putting the segment against the revenue metric, that isn't required.
If you want to return the number of orders for customers that did a search on your site, you would use a visit segment. Because searches and orders happen in different hits, you need to do a visit so that you capture both items. If you were to put "searches exist" in your segment and make it a hit level, and then try to put the orders metric against it, you wouldn't get any results, because orders don't happen on the search page. If you make the segment a visit level, then it would return any order that happened in the same visit as a search. Note, the order could be before or after the search in this case. (You can use a sequential segment with "include only after" logic if you wanted to limit it to just orders after a search was done)
You would use a visitor segment when the conditions you want may or may not be in the same visit. Say for example you want to return orders for all customers that saw a particular page on your website. Creating a visitor level segment would return every action that the visitor has done, when they meet the conditions in your segment. (same as with the visit segment, this would return all orders from the visitor, you can limit it with sequential segments and "include only after" logic)
When you're building segments a lot of times you will want to mix containers at different levels, depending on what you need. For example, if you have a hit level segment and you want condition A AND condition B OR condition C, you would need to use an extra hit level container to put two of the conditions in there, because you can't mix operators at the same level of a segment. So you would need to put (condition A AND condition B) in a hit level container, and then beside that you could bring in OR condition C.
Another time you would use containers is if you need a visit or visitor segment, but your conditions all need to happen in the same hit. Say you want to return all the orders from visits that did a search and saw Product A. You could make a hit level container with the conditions for a search existing and Product A being shown. And then you would put that hit container inside of a visit segment. The reason you would do this is because the hit container insists that both of those conditions happen in the same hit. If you were to put those two conditions in just a visit segment, then it would be a visit that did a search and a visit that saw Product A, but not necessarily in the same hit.
One other point about different level containers in segments. Most of the time you will put smaller containers inside larger ones, such as a hit level container in a visit level segment. But it is absolutely possible (and valid) to put a larger container inside a smaller segment (such as a visit container in a hit segment). The logic for those can get a bit complicated, but it can be a way of limiting what information you return.
Whenever you use a segment there is always the risk of pulling in unwanted data, even at the hit level. Going back to my example of looking at revenue for a group of products. Even at a hit level, the segment will return the ENTIRE hit. So, if I place an order for Products A, B, and C, and then have a hit level segment that says Product A or Product B. The revenue returned is going to be for products A, B, and C because as long as my conditions are met in a hit, it will return all information for that hit. There isn't really a way to avoid this with segments, you just need to be aware of what information you need to return and decide how to build your segment based on that. With sequential segments there are ways to limit what information you return, by using the "include only before" and "include only after" logic.
Hopefully this is helpful. There is a lot more to segments than just what I outlined here. There's also stuff like understanding how to use exclude containers, the time based options for sequential segments, and so on.
