I think the video misses a lot of points. Most of the time you just want one owned String and then pass around a lot of &str references. For the use case they describe where lifetimes make this hard, I don't think the solution is to use Arc at all, but instead use u32 or similar for your id instead of a string id. That is way cheaper to copy around.

There are times to use a Box or Arc str instead, but those are not as common as just string references or u32 ids.

If the data represented in the Arc is supposed to be immutable, why not pass around a reference of Vec<T> instead of cloning the Arc<[T]> over and over? The latter appears more expensive. Arc<String> is always going to be worse than Arc<str> because Arc<String> is roughly equivalent to Arc<Vec<char>>. Lastly, instead of the overhead of a tuple struct, we could define

pub type MonsterId = Arc<str>;

and maybe define and implement traits on it for additional methods.