I've been worried about that too. Recently I learned that libsodium includes a way to generate crypto_box keys from a fixed argument entropy chunk. It sounds really convenient but also circumvents all of the labor around centralizing entropy generation.
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.
It was added after a popular request: providing a simple way to derive a key pair from a secret key, itself derived from a password.
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.
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.