The main drawback of trying to do this might be that the syntax is unwieldy. If you have one big shared object, or shared objects only in a specific part of your program, it's no big deal, and it arguably helps call attention to what's going on. But if everything is using Arc<RwLock<...>>, you'll have .write().unwrap() or similar on every line, and it'll feel terrible.
The sibling comment mentioned cycle leaks, and in addition to that I'll add the runtime panics or deadlocks associated with locking the same thing twice.
Agree that I should not just stick Rc everywhere. The use of borrow checkers makes a lot of sense at a macro scale, i.e: libraries, APIs. But, I’m just wondering the justification for using Rc in a smaller scope, say inside my own implementation of a trait. If I am to provide external APIs then yes, sticking Rc everywhere would not be a good idea ergonomically.
One high level problem with learning Rust is that a lot of the patterns we use to work with the borrow checker are pretty non-obvious. (Things like using indexes instead of references, and avoiding methods that keep &self borrowed.) To the extend that Rc and Arc let you avoid learning those patterns, I agree with folks who say not to use them too much. But if you know how you might solve something without Rc, and you want to try it with Rc anyway to see how it feels, that's totally reasonable.
The sibling comment mentioned cycle leaks, and in addition to that I'll add the runtime panics or deadlocks associated with locking the same thing twice.