Here's the bench mark for both methods.

require "benchmark"

n = 1_000_000
ARR = %w(today is a good day isn't it?)
Benchmark.bmbm do |bm|
  bm.report { n.times { ARR.map(&:capitalize) } }
  bm.report { n.times { ARR.map { |i| i.capitalize } } }
end

Rehearsal ------------------------------------
   1.890000   0.000000   1.890000 (  1.893212)
   1.930000   0.010000   1.940000 (  1.928549)
--------------------------- total: 3.830000sec

       user     system      total        real
   1.900000   0.000000   1.900000 (  1.910439)
   2.050000   0.000000   2.050000 (  2.050394)

@mortonfox, As I said it's a good solution. I think the comments section is a good place to discuss tradeoffs that may not be obvious to evey user, such as performance issues. That way someone seeing these for the first time can make the best informed decision in the future.

The main thing this is good for is being concise. I never believed it was performant since Ruby has special optimization for blocks.

Test cases are broken; as others have pointed out. Would be nice if there was a feature where the community could directly edit the test cases to fix and self moderate. This is an easy fix that would have been taken care of months ago if we had the ability to do some self moderation.

This kata appears to pass no matter what code is used to define the method...

Absolutely, you don't happen to know the Big O time for comparing do you?

Clever is the tag chosen by Codewars; this wasn't some kind of slight. It's a good solution, but performance is sub-optimal and the better performing solution is also easier to read.

And to say "As for performance, don't use Ruby", that's just silly. It doesn't matter what language someone is developing in performance should be a consideration. This isn't a case of pre-mature optimization. It's an easy performance gain. I provided the benchmark for anyone that might come along in the future to be helpful as they may not be aware of the performance difference.

It's not 'clever', it's perfectly readable to any Ruby developer. You could argue that so many things in ruby are not readable to 'the average developer'.
Passing just the method is more common in many other languages, be it Python, Scheme, Haskell, Dart, Smalltalk or even C.

As for performance, don't use Ruby, or optimize inner loops. For most Enumerable#map operations the actual operation will cost way more than iterating in whatever way.

So obvious once I saw it; but didn't cross my mind when I was trying to solve it. Nice one!

This is certainly a clever solution and deserving up the the up votes for that. I'm surprised that this is so heavily upvoted though for "Best Practices", in comparison to the more direct map enumeration version here http://www.codewars.com/kata/reviews/5356b77a2930ee4c010007e6/groups/5397a4c4c20318c06e000ea0

While this technique is certainly clever, I don't believe it is as readable to the average developer and the performance is worse.

The results posted below are from benchmarking this solution against the standard map enumerable. This to_proc version shown here is about 8% slower. So you lose speed and code legibility.

Calculating -------------------------------------
            proc    47.361k i/100ms
             std    52.963k i/100ms
-------------------------------------------------
            proc    980.817k (± 7.3%) i/s -      4.878M
             std      1.060M (± 7.3%) i/s -      5.296M