Great sentiment. One thing that jumped out at me was "Don’t engage in a needless dance where developers have to take several steps to do a single action."
I think if you want to follow the "rule of least surprise" from the unix school of thought, this is probably a somewhat dangerous suggestion. Having one call go and do several things can make that call become something of a black box. It kind of breaks the rule of transparency as well. If I find myself having to do a dance with the API, as the end user there's nothing stopping me from writing my own helper code to group those common calls together; I'd prefer an API with total transparency and the least amount of surprise, which is ultimately more flexible.
Even better, IMO, would be a layered API, with a lower layer of 'atom' (atomic would be a good name, if it wasn't taken for something else already) calls tht do one thing, and a clearly separate layer of 'molecule' calls that help you perform common operations. For example, reading a text file into a string would be a 'molecule' call. That call would not need to be as flexible as a hand-coded open-read-convert bytes to characters- close chain. For example, it could assume a UTF-8 encoding.
I think if you want to follow the "rule of least surprise" from the unix school of thought, this is probably a somewhat dangerous suggestion. Having one call go and do several things can make that call become something of a black box. It kind of breaks the rule of transparency as well. If I find myself having to do a dance with the API, as the end user there's nothing stopping me from writing my own helper code to group those common calls together; I'd prefer an API with total transparency and the least amount of surprise, which is ultimately more flexible.