Focus can remain on the business problem at hand while finding the right components which address that problem rather than on the problems of how to develop new software. You have control over every piece, but you also have responsibility to design, create, and verify every piece. Your design structures have to capture enough detail to support the development of each line of code. When abstraction is gained with these approaches then precision is lost because they do not have the vocabulary and techniques to capture both. Transitions between abstractions are based on informal descriptions of what is correct or incorrect.
Precision is lost.
In the case of component-based development we recognize that there is no such thing as a free lunch. Finding the relevant quality of product and support for the right components has to be a significant part of your process. You can only be sure you are getting what you need if you can precisely capture what you need and validate against that description. You have to be prepared to accept tradeoffs as part of the control you have given up by not developing the software yourself. For example, you may find functionality that you need in components that are greater consumers of resources than any problem-specific software would be.