If the problem domain is well suited to it, certainly.
My current work involves an app that needs to support a variety of capabilities depending on a bunch of runtime factors. Using component based entities to decouple all of those capabilities and allow extensibility and testability in isolation has been idyllic for us.
My work involves providing connectivity to proprietary hardware (in C#). Depending on what form-factor the hardware is, what firmware is installed on it, what level of service the client has purchased, etc, etc. we need to provide different levels of functionality to the device. Even some features that have the same interface have different implementations depending on what version the device is.
Previous codebases here have had very wide interfaces with many not implemented. Some have had many thin interfaces that were then statically composed in one beasty class. Some simply used string -> string dictionaries to model it. (we have many departments who all think they can do it better)
These all have their deficiencies. Wide interfaces are a pain and a half to mock/test effectively. Adding new features means changing the public interface (and all existing implementations). Many thin interfaces led to very ugly consuming code, but since we ended up passing around a big fat object testing still suffered. Plus the thin interfaces didn't manage their dependencies well. String dictionaries have the usual parsing and existence issues and well as performance, readability and maintainability hellholes.
What we're using now is a very slim entity that has its components discovered and composed based on runtime info. Dependencies are done declaratively and auto-resolved by the core component framework. The components themselves can be tested in isolation since they work directly with their dependencies, and issues with missing dependencies are found early - and in one location rather than first use of the dependency. New (or test) components can be dropped in and no existing code is impacted by it. Consumers ask the entity for an interface to the component, so we're free to screw around with the various implementations (and how the implementations are mapped to runtime data) with relative freedom.
For a situation like this where the composition of the object and its interfaces can include some (highly varied) subset of common components, it works very well.