Here are some ideas:
- REST constrains your service to use a uniform interface. You don't have to waste time daydreaming (or arguing) about all of the possibly ways your service could work - you get right to work identifying the resources in your system. Turns out to be a big job in itself, but fortunately the problems tend to be much-better defined.
- With resources, their associations, and their representations in hand, there's really very little to do in implementing your service because many decisions have been made for you.
- Your system will look very much like other RESTful systems; learning curves for teammates, partners, and clients will be reduced.
- You'll have a common vocabulary to discuss design problems with other developers, and even with those less technically minded (such as customers).
- As Darrel says, because you're using a hypertext-driven design, your service narrows the scope of coupling to just one thing - media types. This helps you as a developer because changes to your system are contained within a narrow band of contact. This helps your clients in that fewer of your changes will break their code.
- Almost every problem you might have in implementing REST can be solved by exposing a new resource or re-thinking your resource model. This focus is, IMO, a big productivity boost.
Bottom line, REST removes many of the most time-consuming and contentious design and implementation decisions from your team's workflow. It shifts your attention from implementing your service to designing it. And it does so without piling gobbledygook onto the HTTP protocol.