I guess Apple's ARC needs all the help it can get to catch up with tracing GCs, there is a reason why everyone else in the industry went with them.
Apple's talk about RC over GC is just marketing speak for the failure to have a tracing GC in Objective-C that wouldn't crash left and right when integrated with C like code.
It was a very sound decision given Cocoa semantics, and the difficulty to make anything written in C not to fall apart with segfaults, but lets not oversell it.
Likewise Swift RC makes sense from having to integrate with Objective-C runtime and existing ecosystem, but again that is all about it.
There is no RC implementation with comparable performance to tracing GC languages that isn't just yet another tracing GC from the amount of runtime support needed to make it actually fast.
Swift is a disaster, also agreed. So?
For the rest: actual research disagrees with your forceful but unsubstantiated assertion:
https://2013.splashcon.org/details/oopsla-2013-papers/21/Tak...
And once again, tracing GCs do well in microbenchmarks where you only check the cost of local operations. They are horrible when you take the global effects into account, with those local/benchmarking advantages not translating into real world use.
https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
Very similar to JITs, which also do massively better in microbenchmarks than in production code:
http://blog.metaobject.com/2015/10/jitterdammerung.html
Oh, and integrating well and without high cost to fast languages where you have even more control is actually an important feature.