The need only arises in ascenario similar to the cpython implementation. You have a big codebase that uses Arc extensively in basically all interfaces. However, you have objects of which you know that they exist for the complete runtime of your application, i.e. they have effectively a static lifetime. You share these objects between multiple threads and pay a lot of synchronization cost for incrementing/decrementing the counter so you look for a solution that allows you to use the existing functions and interfaces without paying the reference counter synchronization cost.
The cpython motivation is a bit more complicated because it is not about thread synchronization but about interpreter forking but the point stays the same.
This is such a niche application that it should not be included in the rust std. If you write an application like a python interpreter you should use a custom smart pointer because you probably want to employ several domain specific optimizations (like this one). It is a severe performance cost of several percent for the rest of the users in the current python implementation.