Well, all these points either have a reasonable solution/workaround that doesn't complicate the design much, or describe a quite "marginal" use-case. But the lack of weak-ptr makes impossible an object existence tracking, which is commonly used in a wide range of tasks. In some cases this would complicate the design and make it more error-prone (eg. manual breaking of circular references), and in some other cases it renders completely impossible a use of some facilities (like Boost.Signals2).
Well I wouldnt say these items are 'marginal', because most come from real life scenarios. You can work around things but it is always that u have to remember that there were some boundary cases with shared_ptr. It took me some time to convince my colleagues to swap from raw pointers to shared pointers and having some boundary cases doesn't help then. I still prefer shared pointers, but I am not sure if all in all they would be better than e.g. intrusive_ptr's with ref counting (even without lacking the weak_ptr feature). Note that i look upon this from a client perspective (i.e. large data acquisition application), not from a library builder perspective.