Today, just a historical note on why these methods are named as they are.
What we needed when designing this a few years ago was a way to set at a basic level what kind of access we would provide from the service, preferably in a uniform manner. There are tricky issues to deal with when permissions and models change from request to request, so the simple path discourages this.
Because this was a relatively simple thing, we wanted to keep the API simple as well, so it's just a name and a set of flags (some of which are convenient pre-composed values, like EntitySetRights.AllRead). We also didn't want to invent too much in terms of naming, again to keep things simple.
The inspiration finally came from the FileSystemSecurity.SetAccessRule and the FileSystemRights types. These types are used to work with Access Control Lists or ACLs, which you're probably familiar with if you've ever messed with permissions using Windows Explorer. We simplified this even further, by collapsing the FileSystemAccessRule with masks, flags for propagation and identity into a simpler EntitySetRights, which is the DataService equivalent of FileSystemRights.
ACLs are a much more powerful but at the same time a much more difficult model to work with, and the uniform rights model won in the end (difficult to program is also difficult to test, review, audit, etc.) And so, with just a method and a flag, you can now begin to lock down or expose your data in a simple manner.