Continuous integration => of course, for me, never worked at a place where it didn't happen and that was before agile was even a thing. If I hopped on a project where it didn't make sense though, I should be free to ditch it.
There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.
You argue in favor of not calling things things, and then go on to call a lot of things things. You demonstrate why we need to name things: to talk about them more effectively.
What makes sense to one person may not make sense to another. I agree that each team should decide based what's right for them based on the people and the problems. But to do that beyond the trivial, we need to name things.
You don't need to do any other process. You can just talk to people as problems arise and do that "in stead".
Conceptually, I like shapeup. I think spiral model is fine - I'd argue that a lot of "agile" shops are closer to spiral.
Now, there are tools in agile that I'll vehemently defend, such as continuous integration and retrospectives. I'm a fan of most of the principles, such as "Continuous attention to technical excellence and good design enhances agility." But we are now at a point that if we're going to argue that "agile doesn't work," we've had enough time as an industry to gather around an alternative.