This is the crux of the problem, and is a problem with many libraries, configuration systems, languages, etc.
The author of said tool wants it to be as widely used as possible, so he optimizes for the 100%, going so far up the flexibility curve that it becomes incredibly difficult to do 80% of the things you want.
What these authors should be doing is optimizing for the 80%, which means an opinionated top layer that offers a single way to do everything that 80% of your users would want to do. Then if you're smart, you'll have a layered architecture (which the 80% layer rests upon) that allows the other 20% to learn about how the sausage is made in order to do their complex tasks.
With this, you have a common tool that is at least 80% easily understandable with minimal time investment.
Failure to do this gives you unfriendly systems like CMake, Gradle, OpenSSL, Postfix, and Java's time libraries.
U/X applies to code as well.