"Software component" has the connotation, to me at least, of being an inward-facing _piece_ of one of these products. It is but one component of a system, and thus it is to be understood by its function within that system.
I think in many domains, the best advice is to name those components helpfully, and to think about the component's role in the system. To start adding functionality to the component outside the scope of its name is to invalidate your design. There is no reason to bloat this component. You'd rather create a new component to handle the previously overlooked role in the system. This is made obvious when you take limiting cases, like designing a moon lander. Here, the software design must be purposeful and optimized, and it only needs to work once. In the opposite case, the component is a web microservice - a living thing managed by a 1-pizza team that always needs to be turned on. Uptime and speed of implementation are at a premium, and creative ways to add new functionality on existing systems are seen as a net good. Here, the article's advice might be good.
