Paging @tptacek for comment
I like the author of this article and think he knows what he's talking about.
I like libsodium but do worry about the project getting away from them; cleaning up the API is one thing, adding new crypto primitives is another. Still: use libsodium.
The person whose opinion you really want on this article is 'pbsd.
Is that a good thing to have? Maybe! It's convenient feeling. Is it dangerous? I have no idea—probably? Should it be part of the interface to libsodium? No clue.
By not providing a simple way to achieve something, users end up copying/pasting random code and inventing their own crypto.
Additional functions that libsodium provides over NaCl were added after observing how developers were using NaCl in actual projects.
When you see projects that allocate temporary buffers to store signed messages, and immediately discard everything because all they actually need is the signature, you realize that developers have to work around limitations of the NaCl API.
When the maintainer of the Go bindings reports memory corruption, which turned out to be due to sign_open() requiring an output buffer larger than the unsigned message you might blame him for not having read the fine print in the NaCl documentation. But maybe the API should better match what feels intuitive to developers instead.
And when developers systematically write wrappers (for example around box() and secretbox() functions) to work around the same issues, it probably means that API could be improved.
Adding convenience functions addressing very common needs to libsodium instead of having everybody rewrite their own implementation makes it less confusing and eventually less dangerous.