Developers get these requests all the time:
All of these request have a common form, a want/need for a specific technical solution.
Developers will typically reply absolutely, I'll get started right away! The developer will expend considerable time to fulfill the request. Upon completion, or perhaps earlier if a developer practices iterative releases, the customer realizes what they asked for won't meet their objective. It won't solve their problem or achieve their goal.
Naturally, the customer makes subsequent requests to tweak or replace the original request. Eventually they may arrive at a solution that meets their objective. They may also run out of time and/or money. If they are paying by the hour, the cost keeps rising. If they have a fixed bid, the developer is suffering and/or disputing the changes. Either way someone isn't happy, and that's no fun!
The above scenario would be akin to being sick and choosing your own medication before going to see your doctor. Then, going to the doctor and saying "I need an antibiotic, can you give me that?" The doctor would administer the drug. Several days later you're still sick, so you go back and ask for a different medication. This repeats until you get better, but maybe you end up dead!
Or, say your hot water stops working in your bathtub. You call a plumber and inquire "I need my water heater replaced, can you do that?" They replace it and that night you still have no hot water. You call them out again and have them replace the faucet in the bathtub. That night, still no hot water!
Maybe these things happen at times, but it's not the norm.
Patients rarely will ask a doctor for a particular prescription to their ailment, and even if they do, the doctor will step back and discuss symptoms first. Same thing with a good plumber, they'll ask you why you need your water heater replaced. Either way, the professional is diagnosing the problem before prescribing a solution.
If diagnosis comes first in software development the developer can bring a variety of viable solutions to the table. Discussing objectives first can save a lot of time and money.
There are plenty of reasons, chief of which is we all like to be problem solvers. Most of us will try to diagnose our medical and plumbing problems too, we just defer to the doctor/plumber to make the final call.
I think developers encourage this too, we're avid problem solvers and we love a new challenge. Instead of listening first, we prescribe.
Sometimes solutions are repetitive, so naturally customers see patterns and offer suggestions.
Sometimes in the middle of a development effort, a suggested feature seems simple, and it may be, so why not add it?
It also happens when customers are charged by the hour. Instead of paying the developer to diagnose the problem, they can do it themselves and "save money."
No matter what the cause, it's clearly beneficial for developers to practice listening to the customer's objectives first. Developers should thoroughly understand the objectives before prescribing solutions. Customers need to participate by describing their objectives until everyone understands. Once the diagnosis is complete, then everyone can feel free to suggest ideas, but I would recommend deferring to the developer, they are supposed to be the expert after all.