Except it never really worked that way, which was the entire problem with waterfall. Waterfall works best in a static environment with guaranteed funding because it doesn't react well to shifting priorities. In reality, requirements change and budgets get cut, which sets off a chain reaction of change management activity in a waterfall model. Agile is so much better -- you reassess requirement priorities every few weeks and that dictates what you work on over the next few weeks. In very few situations under which software is developed today is it even possible to state upfront what you need with any certainty. Waterfall assumes that requirements gathering and development take place serially, whereas agile recognizes the reality that they are more or less concurrent.
Waterfall still has its place - if I were developing a nuclear reactor or an airplane, waterfall is still the way to go. But for projects where 100% requirements completeness is unnecessary (and let's be real, nobody runs a full regression suite after every sprint), Agile will get you a better product faster and cheaper. Everything you said is true -- agile is a fertile ground for manipulators, but so was waterfall.
The manipulation is a byproduct of any reasonably large organizational structure, and if you want to stop it, it's got to be a cultural thing. Bad actors will exist under any development methodology, it's up to the leader of the engineering organization to stand up and refuse to allow his/her people to be abused.
It's a two way street though: the business folks need to understand that they're giving up some control and predictability in exchange for lower overhead and faster delivery. This is the hardest part of Agile IMO since most business / product folks don't like not being in control. Agile gives engineering more autonomy, but only if the business respects that autonomy. If the business starts dictating too many processes/priorities, the whole thing crumbles into a waterfall mess (even if you call it "Agile").
Unfortunately, standups, like so much of "agile", are a perfect disguise for wolves in sheep's clothing.
I've been incredibly burned by agile, and I realized it's because agile encourages a developer to let down his or her guard at the wrong moment.
Going through the agile manifesto, I can now see how each one of these has gone wrong for me.
http://www.agilemanifesto.org
"Individuals and interactions over processes and tools". Right, we all get together, discuss what we're working on. It feels very collaborative. But there will be this tool, this time-tracking system, that we'll enter stuff into, and your name will be next to those things with a deadline. If you don't meet it, we'll interact with you as an individual about why you aren't meeting your deadlines.
"Working software over comprehensive documentation". Again, sounds great. Rather than spec'ing out every little detail, let's work together iteratively to get the right product out. Here's the thing - you just allowed the people who are putting your name next to a task and a deadline to never commit to exactly what they're trying to build and by when. The deadlines are yours, but they'll enjoy changing their minds, because, you know, "agile."
"Customer collaboration over contract negotiation". The trap has been set, this is where it is sprung. Most developers, I'll guess, aren't truly in contract situations where there are lawyers and signatures and so forth. The tend to work on internal projects. But make no doubt - if someone can turn to you and say "you committed to getting X done by date Y", and it's in there in the system, you are in a contract situation. But because it was "agile", you didn't negotiate properly, and now you'll get rolled.
"Responding to change over following a plan". I assure you they will hold your feet to the fire if you don't follow the plain that was clearly in the "contract" and documented in the progress tracker system. However, because it was "agile", you never really got them to commit to what they were asking of you, so they retain the ability to change and adapt. If it suits their purpose, so can you, if not, you're "in breach". If it's internal, this isn't some lawsuit, it tends to be a sit down with people, including your manager (and perhaps a few other managers), where people act like they're all here to solve a problem and get things back on track, with a heavy undercurrent that it's your fault.
Standups, while not part of the manifesto, corrupt similarly. Instead of "here's what I worked on yesterday, here's how it went, here's what I'll work on today", they become a daily application of pressure and reminder of deadlines. It appeals immensely to someone who would like micromanage a developer. They're meant to keep communication open in complicated projects where it can be difficult to make estimates under uncertainty (you know, a software project). But they often end up with one person trying to explain complexity to an exasperated (and perhaps manipulative) person who really just wants to apply (often artificial) deadline pressure.
Unfortunately, "agile", for all its promise, turned out to be amazingly fertile ground for manipulators. I think this, more than anything else, is what has so badly damaged "agile."
Waterfall seems like a discredited old system, and I don't love it either, but it has a huge advantage for developers. It requires people who will insist on and enforce deadlines to state upfront, in considerable detail, exactly what they want.