I don't agree. As a library designer you have to DESIGN in the first place. It pays off to think through the use cases of the users of your library. Allowing every possible way of doing things and seeing what sticks makes your library more complicated. You have to test and document all these alternatives. People will inevitably sometimes choose the wrong way of doing things, end up with underperforming or buggy code and blame you.
Especially in synchronization it pays off to go with the simplest solution. Unless you know very well what you're doing (and wrote some formal verification that it can't break under any circumstances).
I pretty obviously didn't mean that the library designers should just throw out a bunch of stuff to see what gets used. Re-entrant locks seem to fall into the same design space that memory checking in debug C runtimes does: you never want to need to use it but if you do need to use it you want it to be there. Designing for the perfect case is poor design, imho, because we live in an imperfect world.
The difference is that memory checking in debug C runtimes doesn't paper over your mistake: instead it breaks your program reliably so that you know you have a mistake. As per the linked article, "While recursive mutexes may seem a convenience for debugging, in fact it's the opposite -- you're better off with a "strict" debugging mutex (like the POSIX error-check attribute) that checks, tracks, and enforces ownership restrictions a "normal" mutex may ignore in favor of runtime efficiency."
Especially in synchronization it pays off to go with the simplest solution. Unless you know very well what you're doing (and wrote some formal verification that it can't break under any circumstances).