I’m a beginner, so take this not as gospel and with a teaspoon of grains of salt.
As with other Copy values, it seems preferable to take the least indirection possible.
For the second one, do you need the double indirection? Arc is already a smart pointer.
Copy means that Clone is just memcpy so it’ll be incredibly fast. In the end, the pointer you’re passing by borrowing will also need to be copied. I think that thinking about the cost here rather than the clarity is premature optimization.
Note that Option<String> is by moveNOT by copy, since String isn't Copy and thus Option<String> isn't Copy either. So there's not much to do with enums going on with it, but about move-vs-borrow in general.
The rules for trivial field-less enums (like cmp::Ordering) are very different from anything involving String.
Note that &Option<String> is a code smell for a parameter. Is there a reason that you need the caller to have exactly an Option<String> variable somewhere that you're borrowing?
In general, it's more flexible for parameters to be Option<&T> instead of &Option<T>, since then people can just pass None.
And that's even more true for Option<String>, since the parameter can be Option<&str> instead -- that way I can pass Some(&blah[10..20]) to it. If that function took &Option<String>, I'd instead have to copy those 10 bytes into a fresh String, then put that String into an Option, and then pass a reference to that.
(For return types you can consider returning &Option<T>, since people can always all .as_ref() to turn that into Option<&T>, but there's no free way to go the other way.)