A Vec<f32> stores a pointer to the memory it manages, which is a sort of [f32]. Every &T is also a pointer to T.
Therefore, &Vec<f32> is a pointer to a pointer to [f32] — meaning that accessing the items in it requires the CPU to dereference two pointers, one after the other. (And one pointer must be dereferenced to even find its length.) Thus, it will often be slower to access, at least when the relevant data is not in cache.
Of course, this may still be a very small effect not worth thinking about, depending on what kind of code you're writing.
However, there's a better reason to prefer to avoid &Vec<f32>, at least if you're writing a function: if your function takes a &Vec<f32> then the caller must supply a reference to an entire Vec<f32>, whereas if the function takes a slice reference, &[f32], the function can work with any sort of [f32] — e.g. a slice of part of a Vec<f32>, or an Arc<[f32]>, or a slice of an array [f32; 1024]. It's both more flexible/general and more efficient, so it should be preferred whenever possible.
Generally, you might end up with the type &Vec<f32> due to generic code (e.g. in iterators) but you shouldn't deliberately continue to use it. The Rust compiler's auto-dereferencing will automatically convert &Vec<f32> to &[f32] whenever it sees that one is needed for a function parameter or method receiver.