Beyond a common confusion I think it’s common practice in many companies that has become a way of working. User stories often describe a solution instead of a problem and can therefore be rather precisely estimated. So after sprint planning development simply follows without further need for thought or discussion . In that way of working user stories are used to chuck developers work into pieces.

Now if you start employing user stories as you should (so describing a need and not a solution) you will probably get very bad results if A) you keep the same planning i.e. expect to start developing right after the sprint planning and B) expect to find a good solution for every need through quick discussion among developers. Depending on the size of the problem finding a great solution can take more than that: user research, design exploration, workshops with PMs, POs, technical experts, you name it. It can even require prior testing before going in to a sprint.
Now I know that in Agile we like to make fast and break later, but it’s rather inefficient to spend 3 sprints developing something just to find out that it is not the right solution for what the user wants when you can prototype it in say Figma and get customer feedback in just a few days.