I have worked on both sides of this in the enterprise world (as a support agent in the middle of dev team, as a end user and as a developer on the receiving end) and it is never simple.
A bug report takes time to make and many times it might take time to reproduce or narrow down to a simple test case.
A developer should of course get the information needed to fix a issue, but very often (s)he can find the issue with very little detective work if they know the product. The problem I've seen is that you have a fundamentally broken system where:
1. The devs don't really know the product in the sense that they do not use it. They have very little experience how it actually is used or the workflows and might not have good overview of the code base.
2. The support agents, if they exist, have little clue of either development or the product and just as a filter to remove the absolute majority of known issues but at the same time mess up the communication between end-user and devs
3. The end user have neither time or experience to test or report issues so you get very bad reports that vary wildly.
When working as a support agent I have spent a lot of my time acting as a filter to stop making the end-users go mad with all the requests from the devs and preventing the devs from being flooded with crap reports (of course, some always slip through). That means a lot of time spent on reproducing and testing (and sometimes pointing out where the bug is in the code, even suggesting patches). But very few organisations pay for that knowledge and very few allow agents to muck around for a day with a tricky issue to make sure the devs can fix it without a major hassle.
It is very easy to ask for more information as a dev, and very often it is needed, but a lot of the time it is just pushing the cost to the end-user when a minimal amount of detective work (or even a single quick test) would do the same and save everyone a lot of hassle. I would argue that in a lot of time when we, as devs, ask for more information we do it to push the issue into the future and to save ourself a minuscule of work now, not to have a quicker resolution.