A good way to look at the advantages of a hypermedia-based API vs an "HTTP-RPC" style one is to consider the differences between "In-Band" and "Out-of-Band" information. A hypermedia API focuses on getting as much information in-band as possible, reducing the burden on clients to deal with changes.
I have several Google accounts: My personal email, Google Apps at my employer, and Gmail for my domain. I use my personal email all the time, and have several Google Docs spreadsheets and letters. Our company uses Google Docs and Sites. Its extremely annoying that switching between these accounts is brittle, and unpredictable. The same situation existed on Github between my personal and the company account, before they added "Organizations".
With the IE9 betas beginning to come out, Microsoft have introduced an interesting new feature they're calling pinned sites. For more details about how it works, you can check out the Ars Technica preview. Essentially, you put several ms-vendor specific meta tags in the html of your header that describe the menu. The example given on the Ars preview uses this markup:
The other day, I gave a brief talk about our HTTP Library, Resourceful. After a few minutes of going over the features, it became apparent to me that very few people have taken the time to appreciate the finer points of HTTP. Everyone who calls themself a web application developer needs to take a few hours to read RFC2616: Hypertext Transfer Protocol -- HTTP/1.1. Its not very long, and increadibly readable for a spec. Print it out, and read a few sections when you go for your morning "reading library" break. Unfortunately, a great many people got confused by it, and ended up reimplementing a lot of http in another layer, and thats how we ended up with SOAP and XML-RPC. There's a good parable about how this all went of the rails for awhile, until some people re-discovered a section in Roy T. Fielding's disseration, "Representational State Transfer (REST)".