Am I missing out on some "REST magic" here?
Not really. I agree with most of what you are saying. But I'll try to address some points in detail.
As far as I can tell, and correct me if I'm wrong, but all of these benefits of "REST" have nothing to do with REST and can be done without it:
Right. I agree that the biggest benefits REST gives you can already be accomplished without REST. I love the consistency that CRUD provides and consider this the biggest benefit.
Probably the next benefit for me is named routes. You don't need a long hash of controller/action names. I mention this in the latest Railscasts episode. While you can do named routes without REST as well, it just takes a lot more code.
1. Nested resources, and their caveats, when I could pass the foreign key in a GET anyway?
Agreed. I honestly don't use nested routes. It does produce some cleaner URLs, but not enough for me to use them.
2. Two meaningless actions in every controller ('new', and 'edit') just to keep in line with the HTTP verbs?
I don't think they did this to keep in line with HTTP verbs. They were doing this way back in the first scaffolding. I consider it more of a separation of concerns. If you try to merge this all into one action it can get pretty complex with a lot of "if" conditions. Separating it out has its downsides too, namely having to recreate all instance variables the template relies on if there is a validation error. There are various ways to get past this though.
3. Faked HTTP verbs everywhere.. what about ajax and having to make everything buttons for that hidden form variable?
4. Constant design issues, interrupting my flow to ask what HTTP verb describes a search or rating a resource in a CMS
I look at it more as a "nudge" saying there's an alternative design decision which is often the better way to go. If you need to add another action to a controller which doesn't fit into CRUD, you can often move this into its own resource which may result in a better design.
I know at least for me, if I didn't have this constant constraint I would be too lax and say "oh, it's okay to just add this other action" and before I know it I have this fat controller dealing with multiple types of resources.
5. Things like restful_authentication - a login is a create and a logout is a destroy? Why?
Not everything fits in REST. I consider this borderline. It does make some sense if you think about dealing with a "session" resource and you are creating/destroying that.
6. Creating and managing multiple models in one controller (which is just about every controller unless all you write is 15 minute screencast blogs) making me stop and think some more
This kind of goes back to point 4. IMO managing multiple resources in one controller is not that bad until you need to create separate actions for that resource. This is where a second controller needs to come in to keep every controller dealing with only one scope.
- Free Ruby on Rails Screencasts