On-topic, I would find huge disagreement with Alex on the statement that utility doesn't scale well. That's simply not the case. The bottom line, of course, is that you still have to end up in "a state" at some point -- regardless of whether you do it through an FSM, BT, utility, planner, etc. You need something that is mapped to an animation, behavior, etc. The only difference is in how you get to that state (i.e. the decision). Sure, you can do hybrids -- which is all Kevin was meaning in his statement to you. However, it is not terribly taxing to do utility-based architectures with dozens or even hundreds of potential outputs (if your animators can keep up) and even dozens (or hundreds) of potential inputs. In fact, I'm doing work for a client right now that is entirely utility based where I am writing a system to add/edit what could, theoretically, be referred to as "infinite" numbers of utility-to-action mappings.
Even more on-topic, the GDMag article Alvaro referred to was mine. And no, it wasn't a utility love fest. Because, even though not necessarily for some of the reasons Alex alluded to above, utility isn't the best answer for everything. In fact, the entire premise of the article was that there is no best answer. It depends.
: Derp grammar.