Passing objectified methods to iterators via &-syntax instead of code blocks

So I'd like to know communities' position on this issue. Say, we have a class that has several accessors:

class A
  ATTRS=%i(a b c d)
  attr_accessor :a, :b, :c, :d
   
  def initialize(:a, :b, :c, :d)
    @a, @b, @c, @d = a, b, c, d
  end
end

And at some point we might want to know if all the attributes are empty (suppose we know for sure they cannot be false). So we might add a method that would look like this:

def is_empty?
  ATTRS.none? { |attr| public_send(attr) }
end

Or we can dive into more obscure elements of Ruby and write it like this:

def is_empty?
  ATTRS.none?(&method(:public_send))
end

What's a good practice and a bad practice in this example, and why?

Another example might go like this. We have a class that contains a collection.

class B
  attr_accessor :collection
   
  def initialize(:collection)
    @collection = collection
  end
end

Collection may be represented in some other way, so we need a method that will transform it:

def transform_element(el)
  # do something with element
end

def transformed_collection
  @transformed ||= collection.map { |el| transform_element(el) }
end

Or, like in the first example:

def transform_element(el)
  # do something with element
end

def transformed_collection
  @transformed ||= collection.map(&method(:transform_element))
end

I strongly believe that a second approach is a wild overengineering, but I want to know what is a communities stance on this and whether this is a widely used way of doing things. If not, maybe it makes sense to add this type of thing to the guide?

P.S.

I do understand that both of these examples are very synthetic in the sense that at least second one may be resolved by moving transform_element method to the class of element of collection and re-writing method as:

def transformed_collection
  @transformed ||= collection.map(&:transform)
end

I just wanted to highlight this one way of doing things, just imagine that third way is not an option for some reason.

Start with the two Ruby examples in the issue and compare their block and &method forms with the style guide's existing conventions. Done means reaching a clear community decision about whether to recommend one form and, if appropriate, documenting that guidance in the guide.