Using reference type over value types is more complicated than just mutability and inheritance. Most data classes in Uber are also classes, simply because there are hundreds of them, and using structs increases the app binary size.

"skilled Swift developer always builds around value type"

"Skilled" swift developer may always use structs, but the real engineers understand, there is no silver bullet when it comes to real-life problems. It’s all about using the right tools in the specific use case. It’s perfectly normal in Apple SDKs to inherit from UIViews, UIViewControllers, UIControl, etc. So it’s nothing wrong with an inheritance from the generic interactor, especially given that:

• it's a part of RIBs SDK
• RIBs components are final classes by default

Besides that, as I highlighted in the article, RIBs enforces using protocols and protocol inheritance, and not class inheritance. I don't see any sacrifice in Swift features, as you can still use any of modern Swift patterns. I worked on multiple projects using MVC in one way or another. Most of them suffer from the lack of unification, where they have a mix of all possible patterns: delegation, callbacks, notifications, KVO, and reactive programming. The main benefit of RIBs (and VIPER) is that it's well structured, organized, testable, and scalable. Everyone who opens a project can debug it in a matter of minutes, because the scopes of responsibility are always unified across the project.

"SDK is not designed around interactors, presenters"

It does actually. Interactors, presenters, and routers are just the human-readable names for delegation pattern, that is widely used across apple SDKs.

"Rewrite this tutorial in Apple MVC and figure out how much shit you don't need as an exercise."

Using the Xcode template eliminates most of the boilerplate code. But it's always a trade-off "development time vs code quality", so the engineers can pick the right architecture for the specific projects.