The attitude that the Developer's rights trump the Customer's rights almost sounds like its own XP pitfall. Alternatively stated: It's more important to maintain the customer's right to "change your mind, to substitute functionality, and to change priorities without paying exorbitant costs" (CustomerBillOfRights) than to increase business value by adding a feature.
Solution: Often, refactoring before implementing a feature -- that is, sitting down with a new story, and instead of starting with a test, starting with a refactoring of the areas of code that will need to be altered -- will actually make it much easier to implement that feature.
Solution: Realize that YAGNI and Refactoring ARE IN NO WAY OPPOSED. They never come into conflict, so there is never a need for one to "trump" the other. They are both implied by Assume Simplicity, applied at different times relative to the code in question:
Solution: "Simple" in "the simplest thing" refers to cleanliness of design, not "minimal changes from whatever I happen to have right now." The latter has its place (see thrashing, above), but if taken too far, everything turns into molasses. -JimKingdon?