The main reason at the end of the day is to land up with an API that is:

a. Fully browse-able with standard web browsers.

b. Acts in the exact same way with a browser as it does with any other client.

The api design functions on the simple idea of having a "GET" request act as a discovery mechanism while "POST" requests perform operations and searches -- much like how most websites function.

I understand you might expect the client listing at GET /clients, but I believe within a few minutes of looking at our design most people can work out its rather a POST /clients/list. You'll be looking at the documentation for almost any api you use, so I didn't really find that to be a major factor.