Thanks for your replies, Laurent and Nexus. Especially your very speedy one, Laurent!
To a less experienced programmer as myself, it doesn't seem like there's a clear and simple answer to the problem of handling the drawing of a compound object within SFML. After Laurent's answer made me question my assumptions, I thought inheriting drawable was clearly a good choice. Now you make me question that again!
The LSP article goes over my head a bit, but I can see where my example of a button - or an even more complex game object such as a vehicle - would probably not violate the LSP if inheriting from drawable. Inheriting from either sprite or shape would violate the LSP. Buttons and vehicles are both inherently drawable objects to my thinking, and at least make sense with the other functions Laurent mentioned above.
However, after my first response, I did spend some time to think about other ways a compound object could be handled. The other method I could see working would be to have the object manage its simple drawable parts in a list of everything to be drawn in a given frame, completely separating the drawing responsibility from the object itself. A button could add a Shape and a Text to a list of all things to be drawn, updating via reference as necessary, or removing its drawables when it is destroyed. Is this what is meant by separating model and view logic? Would that be considered weak coupling? It seems like it would create more chances for things to go wrong, like having difficulty managing draw order.
Would the weakest coupling in this case be having each compound object draw its own component parts when asked?