Fast - If the plan changes halfway through Agile development, how does that NOT result in the same discarding of work and starting over? In my experience it's very uncommon for non-Agile projects to change so drastically halfway through that you have to scrap everything done so far. Has it happened? I'm sure it has. But I'm sure something similar has happened to Agile projects as well.
Cheap - Your conclusion is only valid if priority and value are directly related. Due to the various priorities of different departments, I've not found this to be at all the case. The marketing guys might think it's imperative and of the highest priority that the product use whatever the latest designer colors might be. Does this add value? Not in my book.
Good - I fail to see how short development time necessarily leads to "good". As far as I can see, all it does is lead to doing things in bite-sized pieces. I'm not saying that's a bad idea, but it's been my experience that on any project of real substance it can be very difficult to break everything up into chunks small enough to complete in a week (or even two). We've tried this several times at my company and have always failed. Even with a two-week cycle it was very difficult to break things up into sufficiently small pieces.
I would also suggest that non-Agile development in no way insists on you juggling 60 features at once and not submitting any of them until they're all complete.
You obviously like the Agile approach, and that's great, but some realism in the implied criticism of other approaches would also be a good thing. The non-Agile developers aren't all dunderheads who do everything in the dumbest of all possible ways.