Luis and Max — I strongly believe that you can't afford to not motivate a team along the lines that Luis describes. The difference between a great team experience and a horrible one has everything to do with the team dynamics. That is: trust, shared goals, open communications, support, mutual respect, helping one another — and nothing to do with the "hard skills" of project management, having a copy of Project, or using EVM, or even following an agile approach. This comes from my experience, as well as from explicitly asking thousands of project participants over the years, including rooms full of PM's with PMP or other designations.
We do a reasonable cost accounting on our project retrospectives and sum up the costs of team dysfunction when it flares up on a project, then these costs far outweigh the investment in building an effective team as Luis describes. These range from the hard costs of delays, rework, cost overruns, to the softer costs (though still quantifiable at least by proxy) of turnover or resentment or other forms of "less than 100% committed participation".
We may well understand the ideas behind the Tuckman model for team maturity, and/or the Situational Leadership model for leadership based on the needs of the team. Nevertheless, most PMs today don't appreciate that we can consciously, proactively, build a team to a higher state of maturity so that it functions as the team and the leadership desires. Team building isn't an afternoon of paintball; it has loftier yet still achievable goals.
While most people have lived a great team experience, there remains little formal expression of effective team building practices. The PMBoK merely mentions that the concepts exist. Agilists primarily developed their approaches (such as Scrum) while working in a highly mature team without consciously recognizing the impact of that maturity on their success, so it doesn't get codified into their approach.
At the beginning of a project we should always be conscious to invest in bringing the team together to learn about one another (what makes them unique), and appreciate the skills and perspectives each one brings to the table. We should also appreciate the differences between one another as strengths for the team overall, rather than wedges that will tend to tear the team apart. All this tends to make the team run more smoothly, especially as issues are identified earlier.
That enables the team to collaborate to deal with them when there are more options to choose from, and leverages all the strengths the team can bring to bear together on the problem. It tends to bring the overall effort down rather than up, and improves the product quality in the process. There is far less talk about non-performers or overbearing bosses, less turnover, and silos are removed. This is not merely theory. I have done this myself in practice.
Max
Wideman Responded 
