I can't disagree more strongly about this. Many, many times I'm trying to understand a codebase, and what I have is that codebase, not the dozens of dependencie

I can't disagree more strongly about this. Many, many times I'm trying to understand a codebase, and what I have is that codebase, not the dozens of dependencies involved, and not a full development/build environment. I may not even know what, if any, IDE the original developers used. There's also very common sources of bugs when functions take multiple arguments of same (or sadly in some languages, implicitly convertible) types. With named arguments in complex functions, you can sit down, read the code, and spot the bugs. Happens frequently enough in code review that we have a category for it. Without named parameters here, every single function call becomes a game of "mouse over the parameter in the IDE". Moreover, "you can just read the docs inline in the IDE" also causes people to not think much about naming things, which also harms maintainability. It's a real issue in large, long-lived codebases that may not seem like much in smaller projects.