There is often a difference between what the customer says they want (which they label "requirements") and what they actually need. Sometimes they need to be told no, and when they ask for the third time and nothing's changed, that's definitely crap that your developers should be shielded from.
Just a further point, often the both you and the customer agree that there is a problem that needs addressing, but the customer is not sure how it should be solved. Alice from accounting wants the system to do X, while Bob from compliance needs it to do Y, which directly conflicts with X. Finally Carol in management has determined that they are not going to pay for a solution anyway.
This is exactly the 'crap' that you need to shield your developers from. Shielding developers is a lot deeper than just ignoring requirements.
