1) I'm working in a TypeScript codebase at work right now where people are often struggling with the types, because one of our main libraries got way too complex with their generic aliases. It creates error messages that are impossible to follow, and it's become a real drag on productivity, even in a library. This is in contrast with other TypeScript projects I've worked on that used different libraries and did not face this problem.
2) Bagel is being intended as an application-focused language (not unlike Go in that way). Not that people couldn't or wouldn't write libraries in it, but the expectation is that the most fundamental and general constructs will come batteries-included.
Expressivity is a double-edged sword. I'm making a particular choice about how best to strike that balance for Bagel's intended use-cases, and I'm going to see how it pans out. It also isn't set in stone yet; I plan on doing some projects in Bagel before all is said and done, as a way of seeing how this stuff impacts projects in practice.
In application code, maybe; it seems to be more the kind of type-system feature that is useful in enabling more powerful libraries of abstractions than doing much for applications, as such, given the assumption of equivalent available libraries.
OTOH, while language expressive power isn't the only factor in what libraries are written in and for it, it is a factor.