It looks like they've conflated type with class. If so, that's the antithesis of duck typing. The impedence mismatch to Ruby seems to me an overwhelming contraindication.
Not sure you can call yjis conflation. From what I've read that was a deliberate thought out decision and a nominal type system is as valid a choice as a structural one and generally better understood in research and industry.
Having said that as far as I understand, type support in Ruby 3 will not prescribe which type checker is used and what limitations exist. Some of the mentioned projects are structural and I think even Sorbet might add support for it at some point.
That is exactly the category error I am calling out.
In a duck-typed language, type is defined by the willingness of a message receiver to receive that message. Class, inheritance, composition are all means to achieve this, but the type of an object is determined by its signature, not its ancestor chain.
The docs say "Every Ruby class and module doubles as a type in Sorbet" and it was explicitly described as a nominal type system in a talk at Strange Loop 2018.
Classes are types by default, but you can define non-class types as well: https://sorbet.org/docs/abstract