"Protocol is an abstraction for a needed dependency, and if dependency is not needed, there is no need in protocol."

Disagree with this one. One can indeed abstract dependencies as protocols, but in Swift a protocol is largely an expression of a desired behavior.

Coddable, Equatable, Hashable, Sequence, Collection.... all basically tell how an instance of something will behave or they tell you about the interfaces or functionality that object can support.

Jim tends to rant about dependency injection, even though one of this proposed solutions is a classic example of Interface Injection. The downside, of course, being that it's similar to the drawbacks of accessing singletons: you now have a hard dependency on that specific behavior.

He also doesn't like injection of protocols, even though that's really the only way to alter the behavior of a system for testing or mocking purposes.

Then again, he doesn't really seem to believe in testing or mocking either, which usually lets him get away with it.