I think this is a natural consequence of low-level APIs. Anything deemed worthy of being configured by caller is made into an extensible interface, whether that be through flag arguments or types. Unless some lib is very opinionated on how things should be done, the extension/customization hooks have to exist in one form or another.
To satisfy the two camps though (low level control vs "give me some sane default or package up common combinations") someone just writes the higher level API on top.
It is entirely possible to write a highly configurable interface with sane defaults. Indeed, the proposal in this article goes a long way in that direction.
Sometimes the right defaults depend on context unavailable to the low level library author. But irrespective of who provides the higher level API, the bottom line is that there needs to be an API that's most flexible when the flexibility is warranted. This is really in reference to Colin's "nothing more to add" remark.
If there is some other context that is unavailable to low the level author, then that default should be provided by whatever higher level is providing said context. C++'s namespaces provide a super convenient mechanism to make that work smoothly.
To satisfy the two camps though (low level control vs "give me some sane default or package up common combinations") someone just writes the higher level API on top.