Exploring the Pitfalls of User Story-Only Requirements

Hi everyone,
🤷‍♀️ I feel unfortunate when I see that requirements consist only of user stories.
A narrow view, lack of proper analysis, and many questions and missed requirements discovered during development by the team are the shortest ways to describe the consequences. But right now, I’m not thinking about them. Right now, I’m searching for why this happens.

🤱 What are the reasons for this?

❔ Simply a misunderstanding that a user story should be the result of analysis, and thus the result of many other artefacts?
❔ The influence of the distorted Agile principle “Working software over comprehensive documentation”?
❔ Lack of time and inability to justify time spent on analysis?
❔ Weak skills in using techniques?
❔ Inability to combine techniques?
❔ A sincere belief that user stories are the entire job of a Business Analyst?
Just laziness?

💹 We have all been at the stage of “requirements = user stories” at some point; some are still there. However, I strive to raise the standard, motivate self-development, and thus develop your team and product/project. Therefore, I want to find and analyze these reasons.

📅 Tomorrow I will uncover a possible reason: “I don’t know how to combine techniques.” For now, I ask you to help me gather as many possible reasons for ignoring techniques as analysis tools and jumping straight to user stories.
What reasons do you see?