Using &block in the signature does not indicate that the method yields, it indicates that the method reifies a Proc. To me, its a sign that the method does something which makes it likely that the passed block will be called outside of the usual lifetime of the called method.
Now, it may be an issue that Ruby has no self-documenting signature element which indicates that a method expects a block for the purpose of yielding without reification, but overloading the signature element which is for reification doesn't really address that (and, destroys one element of self-documentation in order to create another one.)
Furthermore, if you pass it a block with & on the call-side, it's not really reifying a block anyways (even if there is still a performance penalty, which I've never checked), so it's not even true that's what it means in general.
The truth is all functions take a block in ruby. Only some of them do anything with it. Given that, indicating that you take a block with the &block argument seems entirely reasonable to me, if you don't mind the performance hit.
Code is read from top to bottom, and finding out that a method uses a block after reading through most of it, is confusing, whereas `&block` in the method signature clarifies that this method will do something with a block.
The performance hit, as bad as it may be, is not something that should be a concern in many programs. After all, you are using Ruby...