It's different for the different guidelines.
For #3 it's essentially 100% because of the "create and return" part. There's basically no reasonable way to have a fn foo<'a>() -> &'a str function -- either it leaks memory (obviously bad) or it can only return a string literal (so limited as to be largely irrelevant). (The exception here is if "create" doesn't apply. If it's actually returning subparts of a parameter -- substrings are the usual example -- in such a way that lifetime elision applies, that's pretty common.)
For #1 it's probably 95%+, but depends greatly on the domain. As the saying goes, references in structs are "the evil-hardmode of Rust that will ruin your day." Sometimes they're needed for particular tricky kinds of memory usage optimizations or handle types in libraries, but they're definitely to be avoided. (One exception here: something like a Vec<&str> inside a function can be useful, and not too problematic because it's not escaping the function so the lifetime logic might be easy -- such as if all those &strs are substrings of a parameter &str.)
For #2 it varies wildly. As you get more used to thinking in terms of ownership, you'll start writing the type that best fits the ownership mode you're going for with the intent of the function, before even thinking about how it'll be implemented. None of Vec<f32>, &mut [f32], or &[f32] are "best" in any way; it all depends what one plans to do with them. (You do this outside of programming for real-life objects without thinking about it -- you don't invite a friend to your house by giving them ownership of your house, just its address. But if you're moving to a new city and thus sell your house, you don't do it by giving someone the address so they can make their own copy, followed by you destroying yours. Now, obviously that analogy is imperfect in many ways, but hopefully it gets across the intent.)