interesting - not sure if it's really needed though - I've used Redis and Resque before and found it's performance was blisteringly fast. (Resque was made by Github https://github.com/blog/542-introducing-resque)
It isn't about speed or choice of queue, it's about a standerized API for working with queues so you can focus on developing your application domain. You will still be able to use Resque or Sidekiq or DJ or anything else, there will just be a standard API for all of them to use.
Also, it's an ecosystem feature. If a library or a component of rails (e.g. ActionMailer) wants to process something in a background queue, the choice doesn't have to be between a host of bad options:
* Forcing a dependency on a particular queue
* Writing a wrapper for all possible queues
* Falling back to queue-less behavior in the absence of a detected queue
They just use the Rails queue and it works on whatever real-world queue the user picks. Definitely good infrastructure IMO.
I think the point is to provide an abstraction layer, so that the community has some common feature set and protocol expectations when we're discussing different technical solutions to queuing.
