You are describing what happens when developers start building without proper leadership or product definition, not a problem with any development methodology.

Points 1-3 are based around the concept that you don't know where you're going when you're developing in agile. That's not true unless something else is fundamentally wrong.

If you don't know where you're going, you shouldn't start doing anything until you do. That's true of agile, waterfall, building things in the real world, and honestly even just getting in the car and driving.

Point 4: Sorry you had that experience, it isn't universal. I'd also say if a person is unable to explain things to a non-technical person in terms they can understand, it's usually the explainer who has gaps in their understanding.

Point 5: I believe the term for this is called "projection."

Point 6: See point 5.

Point 7: Iterating on a product based on user feedback over time typically does result in a better outcome than trying to project what needs to happen years in advance. A rigid project plan that doesn't take business reality during the time it was developed is a massive problem, and why agile exists.

Point 8: If you're writing application specs on post it notes I really don't know what to tell you. There are dozens of very good digital tools to handle requirements, user stories, user feedback, and bug tracking.

Point 9: Not sure what you're asking here, or if this is a Buddhist thought experiment or something. "If a tree falls in the forest with no one to hear, does it make a sound?"

Point 10: That's projection again. There are many people who have successfully completed agile projects. I'm sorry you had a bad experience or several, but it isn't universal.