Slide 87 of the pdf has the best summary, but the main thing w/r/r REST is that get/put of entire resources can be too heavy.

1. custom methods let you get/put specific fields, without having to transfer the whole thing or split resources up as you add new methods.

2. custom methods avoid needing to implement complex or heavy state mutations on the client. the example was rotating an image 90 degrees; you wouldn't want to download an entire full-res image to your wimpy battery-powered phone, rotate it, and re-upload it when you can just do that on the server.

(... of course this should just update some orientation metadata instead of resampling the image -- it's just an example)

As for your point 2, if you consider a REST resource as a collection of fields, you can update it without custom verbs:

  GET /resources/picture/orientation => 0
  PUT /resources/picture/orientation?value=90

REST is not so much about a simple API, but a scalable service. Custom verbs break scalability.

I believe the issue with Rdio is not that they need custom methods, their API should just be GET, PUT, POST, DELETE, etc. but that they are passing what should be the resource as a parameter

Those are not restrictions to REST, since REST doesn't make any specific claims about how to use things like filtering, sorting etc.

Google created GData2 as an extension to AtomPub format, which only specifies a common envelope for resources (Atom Syndication Format) and how to talk about collections of resources (AtomPub itself).

There is another notable extension to AtomPub format from Microsoft called OData.

Note that there's also a pdf if you don't have the time for the whole video.