For example, having to wrap values in `T.must`, `T.nil`, etc. is a net loss. I read Ruby code full of Sorbet annotations and I wish they were gone.
You're adding useless boilerplate to satisfy the tool, and you have to change your code in unintuitive ways so the tool can understand it.
IMO the Sorbet additions do impact readability, but it dramatically improves understandability. In a codebase past a certain size/number of contributors, you're always going to have ambiguity about what sort of data you're working with. For example, in my part of the codebase we have models representing an entity that is identified by a number in external systems and represented as a whole data object in our code. If I have `foo.entity`, it's unclear just from the "real" code whether that'll return a data object or just the numerical identifier. Having the Sorbet annotations on that method (and available on hover in the IDE) make it a lot easier to navigate the codebase and resolve these ambiguities.
On a smaller code base I may not bother with it for the reasons the original commenter mentioned.
The numbers and testimonials in that presentation are two years old at this point but I can only think that means they’ve improved since then.