I omitted specific examples as it's just really tricky to make them general. It really depends on the environment, intended audience (kernel programmers are not Rails programmers), and most of all: what you're doing.

For example, sometimes a single function with 5 parameters would be bad UX, whereas in other cases it might be a good option, if all 5 really are mandatory for example, or if you use Python and have named parameters. In other cases, it makes more sense to have 5 functions which accepts a single parameter (no one likes "foo(true, true, false, true, false)").

Not all GUIs are the same either; specialist tools can get away with certain "difficult" UI conventions, since people will be trained for those tools, whereas GUIs can't. A lot of design choices are trade-offs without a single objectively "best" solution.

I actually trimmed down the article quite a lot from the original draft I wrote over a year ago, since I didn't want to get bogged down in "details" about these kind of things, as I could think of a whole bunch of exceptions for every general piece of advice. So instead I opted to try and get the bigger point across that an API (any API) is something humans need to interact with, and is a "user interface".

As for documentation: yeah, I agree. I actually like writing documentation and I'm often dismayed by the poor quality documentation out there, even from people or organisations I know can do better.