It's interesting that inheritance vs composition comes up, since one of the most common criticisms I've heard is actually the opposite (that there's too many different objects to get things done).
However, I do understand why you might think this: protocols, which is probably the first thing you touch in Twisted, are usually implemented through inheritance. For resources, the default implementation that you subclass (twisted.web.resource.Resource) contains a bunch of behavior that you almost certainly want.
The important thing to remember is that this inheritance is only to get default behavior. If you want to implement it without inheritance, Twisted very clearly and explicitly defines the interface you have to implement:
https://twistedmatrix.com/documents/current/api/twisted.inte...
https://twistedmatrix.com/documents/current/api/twisted.web....
These are just two examples: Interfaces are all over twisted.
And, to quote from the article:
It doesn't need to be that way, though. When you create
an object, it is best to create it as independently as
possible; to test it in isolation; to discretely separate
its every interaction with the outside world so that they
may be carefully controlled, monitored, intercepted an
inspected, one iteration at a time.
This has recently come up in the async-pep conversation on Python-ideas. If you have a significantly better solution for e.g LineReceiver, I'd love to steal it!