@ambition - not a snarky question at all. The Rails book market is certainly growing crowded, so I think it is a very valid question. I hope this isn't a cheesy thing to say, but I really tried to make this the book I wish that I had to guide me after I had been experimenting with Rails for a while.
This book is different for a few important reasons:
First off, it speaks to issues of design rather than issues of API. That has important ramifications in the way the material is covered. Agile Web Development with Rails (Pragmatic) and The Rails Way (Addison) are two fantastic books, and both are on the shelf next to my desk right now, but they both concentrate on exhaustive coverage of the Rails API. The Art of Rails is meant to be the kind of book you buy after owning one of those. It takes someone familiar with the /syntax/ of coding Rails and attempts to provide guidance and insight into the /style/ and design patterns of architecting an entire application with Rails.
Second, it devotes three whole chapters (8, 9, and 10) to developing with the "Ruby style". So many web developers learn Ruby because of Rails that they eventually get to a point in their Rails development skills where they stand to really benefit by taking a few steps outside of Rails to learn how Ruby is a fundamentally different language than {PHP, Java, other OO/Procedural languages}. The Art of Rails really devotes a significant effort to talking about the new and Ruby-centric design patterns that constructs like blocks, Procs, method_missing, and instance_eval make possible, and then it provides examples of how you can use these design patterns in your Rails applications.
Third, it backs up design patterns with useful, concise examples that you can actually execute, but otherwise stays clear from drowning you with example code that is better left to online format.
Finally, I wrote it to read cover-to-cover, or at least a chapter at a time, whereas a lot of tech books these days are really centered around dictionary-style reference lookup. This book should be fun to read, have you nodding your head, and leave you with some useful abstractions, coding techniques, and new tricks when you're done.
I'll stop here to prevent myself from leaving a run-on comment, but thanks for pushing back for more justification of the book