+1
You are right that comments should explain the "why" and not the "what". But not every single tiny little method needs to explain the "why" of its existence. Do you think hundreds and hundreds of #initialize methods need to explain themselves with a comment? I don't.
Also a big issue I have with smalltalk in general. All this spaggeti mess I see unfold before my eyes in every library I see. One method calling another method which calls (excuse me, I should have said "sends a message") another and before you know you forget where you started and where is the end. Its the definition of Code Labyrinth. All this hectic browsing around could have been avoided so easily with a single comment.
Your frustration about use of the Composed Method pattern is due to a tool shortage, not a shortage of comments. Above, you're talking about getting "lost" as you trace through senders and implementors. When each sender/implementor either opens up a whole pane or, in some cases, a whole new window, then yes, it's very easy to get "lost" and forget where what you were doing due to following side-tracks.
That's why I use Squeak's MessageTrace, it handles this better than anything else in any Smalltalk. It is a "lightweight" way, in terms of gestures and UI elements, to trace through code without getting lost. I wish Pharo would consider implementing a tool like this.
Can you explain it? This is the screenshot? The top line the sender for ensureSecondaryLinkConfigured then see its senders? Its self sends? Because I want (and I was thinking about that too for long time) something like that.
I would like to note here that I am also a big fan of small methods and that my question is not related to whether methods should be kept small and readable but whether comments are really needed for those methods.