So, that the function reifies the block is not part of its interface, though, it's part of its implementation. If anything it's a problem that this implementation detail leaks out through the interface.
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.
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.)