In general, you should pass a slice whenever you don't need to accept a more specific container. If you don't need to take ownership of elements or to grow the container, then there's no reason to pass a Vec by value or by mutable reference. (And there's no reason to ever pass a Vec by immutable reference.)
Also, slices are often more specific than you actually need. If you don't need random access, it's often better to take impl IntoIterator<Item=...> instead.
As with anything borrowed - more often no then yes. References are temporary, but structs are usually thought of as something long-lasting, therefore owning everything it contains. For view-like structs, which are temporary themselves, that's probably a good idea, but whether this view-like struct is a good idea by itself - depends on the use-case.
The owned variation of a slice is a Box<[T]> boxed slice, it'd be much likely (although still relatively uncommon compared to Vec) if you don't need to resize since a Box<[T]> doesn't need to store the capacity which gives you a smaller struct.
Box also implements FromIterator, so you can collect to it as well..
If you pass a varying number of items to a function, you should almost always use slices.
Never use &Vec as an argument, as it's as limited as a slice, but less efficient and less flexible.
Use &mut Vec only if the function needs to change number of items in the vector (e.g. append to it). &mut [] is fine for modifying existing contents.
The exceptions are:
if the method is going to keep the elements (e.g. it's a fn new() or a setter), then you can take Vec or impl Into<Vec> as an argument.
if the number of items can be quite large, and the function is able to process them incrementally one by one without keeping them, then you can take an iterator to support processing with a lower memory footprint.