I agree, and I also find that it's mostly developers with experience that are able to do it... but it's not because of seniority: it's because people with 10+ years of experience simply had to learn it in the past.
In the past there was no choice: developers would talk to users and stakeholders and collect information.
Today there are few opportunities for a junior developer to do this.
That would be really cool to do. One of the reasons I became a dev is cos I used to work for customer service in a games company and I was frustrated with the fact that there were ongoing bugs that I could've fixed if I was in the dev position. In reality, as a dev I am now on the other end where we never really hear feedback from users and there always seems to be some agile race to the bottom where we try to fix as little as possible as simply as possible.
I had several instances of product people asking stakeholders, users and support people not to talk with developers. Prioritisation had to go exclusively trough them.
There was constant complaining from both sides: from product that "tickets opened to us are horrible, support/customers are ignorant" and from customers that "nothing ever gets done here".
In the end nothing of that was true. Nobody was ignorant and a lot was getting done.
> always seems to be some agile race to the bottom where we try to fix as little as possible as simply as possible.
Yeah, that's not agile. The entire point of agile is that you close the loop and the reason you break your work into smaller chunks is so you can deliver them faster in order to gauge the feedback of that chunk and better understand what should be delivered in the next chunk.
If you're not closing the loop, you're not doing agile, you're just doing waterfall with more bureaucracy.
In the past there was no choice: developers would talk to users and stakeholders and collect information.
Today there are few opportunities for a junior developer to do this.