Too much involvements of the customer in the process make him start expressing his wishes rather than his needs to the software
Are you developing software based upon what a customer needs? What if a customer wants? Will you deny the customer because "hey customer, I only build software based upon need!??"
I interned at an extreme programming and agile shop. I saw first-hand weekly customer interactions that at times drove QA and developers nuts. But they delivered exactly what the customer wanted, when he wanted it, and it was clear during "Show and Tell" with the customer what he did, what he didn't, and what should be as he wanted.
Many products have multiple customers which lead to conflicting needs and opinions leading unnecessary blockades
Not unnecessary blockades if the extreme and agile shop make it clear the objectives of implementation and what will and will not be incorporated in the product. Different versions of the same product is also a possibility and it depends upon what is negotiated. This need not be a point of contention that halts productivity or leads to unnecessary blockades.
Many products don’t have any external customers (products organization made for them or to be selling in future). In this case the team itself is playing the user as well as the developer hence killing the effectiveness of the process.
Not necessarily. Even external user interface whereby one is interviewing people at random on the street to determine what an interface for a particular device would look interesting to them is a possibility.
Not many things exists in formal documentation, this informality leads to vague vision and can create problems where the customer might say that this is not what we asked etc. etc.
Then formal documentation need be employed. Formal documentation holds the customer's feet to the fire and a "this is what you told us you wanted" one-line punch-card coincides with the documentation and customer interaction so there are no excuses. As I had opportunity to see this in action as an intern at an extreme and agile shop, the customer signed off on documentation weekly. The customer also had a chance to implement changes and had to sign off on those too. If there is a lack of documentation, there is an invitation to disaster.
The questions is why such conflicting opinions exists regarding XP, is it the matter of different scenarios or is there something else and till what extent the claim (as written in the title) is true.
I would say that depends upon the intelligence of the shop. XP and Agile are guidelines and not instructions. To operate successfully with XP and Agile, it has to be incorporated into operating practices and utilized throughout whole organization. Mileage will always vary and some will undoubtedly claim it is bad, some will say it is good. where I interned, it was undoubtedly good and much success was had.
From my experience, how rigid one is to the principles of XP and Agile appear to determine if, when incorporated into the "daily grind", how successful it makes software development. Where I interned, customer interaction drove everything and nothing was done without a customer having first stated it should be done. The way this shop ran its' operations provided good, measurable success using sound principles of development as part of the XP and Agile framework tightly integrated into everything they do.