Many of the primary tenets of the Rational Unified Process are part of XP. We've been using the Unified Process for many years and see the value in most of their recommended practices. We view some the new ideas in XP to be the strong emphasis on pair programming, unit tests, and refactoring.
There have to be more guidelines for this. Sometimes a module is too small for two people and one person can better handle it. Also, using a fairly thorough design/code review regimen, you can make sure no one gets away with shoddy work. Finally, if you're working on a time-critical piece, sometimes an inexperienced partner slows you down. The concept of pair programming is not universally applicable.
During interviews, we are keenly interested in what candidates have personally accomplished. Weak teammates can require lots of hand-holding and their lack of contributions can be hidden by pairing.
And just because something is uncommon, we're willing to live without it, give up on ever having it and downplay the importance of getting it back? I have never worked for a company or organization that routinely required me to work overtime and I see no reason to start now. Neither does my family.
We are unconvinced that XP works well for large teams or projects (LargeExtremeProgramming) or even small projects that do not have enough experienced, knowledgeable, and disciplined developers. No methodology will work without the right people
Role of metrics is not well-defined - which ones to use and how to gather them?
How to write/automate them for large, distributed, GUI-based systems? (See GuiTesting)
We're not convinced that building unit test cases before coding is a good idea. XP discourages design documentation but suggests building executable test cases before coding! Talk about a heavy artifact that needs to be constantly maintained. In most cases, test programs that are written prior to design/code would be obviated by the time the classes are implemented.