The Fallacy of "All Requirements"

Often I hear: "We have to implement all requirements, and it simply takes as much time as it takes; we cannot stop before all is done" and I see them thinking "Why don't you understand this?" What all is, usually isn't really clear, should be defined by the requirements, and supported by the business case, which in most projects isn't clear or even known to the project either. These people for some strange reason forget that delivery time is as much a requirement as 'all' other requirements, and often it's even the most important one.
Developers are supposed to know how to define real requirements, and they also know that defining the right requirements is not easy. For most customers, defining requirements is not a part of their normal work, so for customers this is even more difficult. How can we expect that customers can properly provide us with the right requirements?
Customers specify things they do not really need, and forget to specify things they do need. It's the challenge for the project to find the real relevant requirements, together with all of the relevant Stakeholders. Furthermore, the Requirements are what the Stakeholders require, however, for a project, the Requirements are what the project is planning to satisfy. After all, we can make great systems, but if the customer cannot afford the cost, or has to wait too long, we both lose. Because there are always conflicting requirements (e.g. more performance can be at odds with acceptable development time or cost), the design process is there to balance, and come to an optimum compromise between the conflicting requirements. The notion of 'all' requirements pretends that 'all' requirements can be met concurrently, or even are known. If this were the case, projects would be a lot easier. We know better, don't we?