> If a function is only called from a single place, consider inlining it.
A compiler should do this for you.
> If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that.
This makes no sense to me.
> If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters.
This can be useful, but only if it does not mess up code readability unless you are trying to squeeze your code into a cache.
> If the work is close to purely functional, with few references to global state, try to make it completely functional.
This makes very good sense, but it can be harder than it seems. One of the easiest ways (depending on how far down the call stack you are) you may just be able to pass the individual parts of that global state in as parameters.
> Try to use const on both parameters and functions when the function really must be used in multiple places.
Not all languages support this, but where they do this is good practice. In general: limiting scope and mutability is always an advantage.
> Minimize control flow complexity and “area under ifs”, favoring consistent execution paths and times over “optimally” avoiding unnecessary work.
Is also good advice.
In general you want to avoid nesting your ifs too deeply because at some point you lose track of what the local context is that got you there. Then it is usually better to break out a function and name it well so that that context is clear again. In general, naming things well is hard.