> Leaving the handling of the loop to the method allows us to add behaviour to loops that are controlled by the object and not by the user. This is a nice way to add side-effects.
No, it's an absolutely horrible way to "add side-effects" which, usually, is already a horrible idea in its own right.
> Asking an object to iterate over itself allows objects to develop interfaces that dictate how to iterate.
That's true in pretty much any language? And since you need to know which iteration interface you need to use, it's not that much of an advantage.
> And now, when I see: `10.times { |i| puts "i = #{i}" }` I do not see a loop anymore.
Yeah, because it's not a loop: it may or may not run that block 10 times. Seriously, when a programmer's intention is "run something 10 times", the resulting expression arguably should not be "send that something to someone who, hopefully, will execute it 10 times".
Strongly disagree. THE ENTIRE ETHOS of Smalltalk & Ruby is to leave things up to the object you're communicating with, rather than the call/send site.
Sure, you may not like that mindset, in which case, smalltalk/ruby are ABSOLUTELY not for you. You want something else.
Which is totally fine. Part of the reason behind the Cambrian-explosion of higher level programming paradigms since the 1960's is precisely because there are multiple ways to skin a cat, and different ways resonate with different folks.