So a wrapper around a wrapper. Or a tool for a tool?
When a tool is great, that is rich and flexible, its learning curve is necessarily long. And what human beings need when it comes to learning (in any field, not only IT) is a fast and easy way to make ones first steps.
When you work in a given context, you always do more or less the same things. If you have a "tool above a tool" that makes your first steps easier with the underlying one, you can make sense out of what you learn because it pertains to what you're working on. Then, you can easily and gradually learn more because you don't start from scratch and your knowledge increments keep being meaningful to you.
If you later work in a different context, the "tool above the tool" might still be useful, not for learning but as a kick starter if both contexts differ a lot.
Such tools are important in terms of risk management because tools embed corporate knowledge and best practices. If an experienced developer leaves your team for any reason, you'll be happy to have such a tool so the new joiner will not have to go through the full length of his former colleague's learning curve, with all the unpleasant implications this inevitably has for the project.
Tools have a cost, not only an acquisition cost, but also an operating cost, mainly due to the complexity added to the work environment. This cost should be estimated and compared with the costs likely incurred otherwise.