>Also they can lead to a poor pattern which is functions/methods that take too many parameters.

>In addition, positional arguments are simply easier to read; as keyword arguments are not ordered, you’re essentially parsing the arguments, seeking the important ones etc.

Microsoft's raw Win32 API SDK is based on the C Language and even though that language doesn't have named parameters, it still did not discourage functions designed with lots of parameters that's difficult to mentally parse.

To make such code self-documenting, this is how I typically write Win32 API calls to make the code readable:

  ret = CreateProcess(NULL, // _In_opt_  LPCTSTR lpApplicationName,
      cmd, // _Inout_opt_  LPTSTR lpCommandLine,
      NULL, // _In_opt_  LPSECURITY_ATTRIBUTES lpProcessAttributes,
      NULL, // _In_opt_  LPSECURITY_ATTRIBUTES lpThreadAttributes,
      TRUE, // _In_  BOOL bInheritHandles,   
      CREATE_NO_WINDOW, // _In_  DWORD dwCreationFlags,
      NULL, // _In_opt_  LPVOID lpEnvironment,
      NULL,  // _In_opt_  LPCTSTR lpCurrentDirectory,
      &si,  // _In_  LPSTARTUPINFO lpStartupInfo, 
      &pi);  // _Out_  LPPROCESS_INFORMATION lpProcessInformation

If the language had named parameters, I wonder if Microsoft would have used them so programmers wouldn't have to sprinkle extra comments like that. (Comments are also brittle because they're not real tokens that the compiler would check.) Without the comments, it looks like this:

  ret = CreateProcess(NULL, 
      cmd, 
      NULL,
      NULL,
      TRUE,
      CREATE_NO_WINDOW,
      NULL,
      NULL,
      &si,
      &pi);

All those naked NULLs and TRUE params are very hard to parse unless you've memorized the positions.

I'm not recommending that we need the verbosity of Objective-C named parameters but I don't see how mentally relying on position is less cognitive load.