Use REST because it's a convention. As far as I can tell, there is no other earthly reason to use it. It certainly doesn't simplify the coding of web applications.
In fact, REST barely exists in the Django world. The problem that Rails solved with CRUD, Django solved with the Admin interface.
REST simplifies web applications because it works with the behavior built into the different levels of the web infrastructure. Browsers pop up a dialog box if you try to go back to a page requested with a non-idempotent method (anything but GET or HEAD). Caching servers treat non-idempotent requests differently from idempotent requests, etc.
Understanding what REST actually means and whether something is RESTful isn't always obvious. To me it means use the appropriate HTTP method as defined in the RFCs; use the URL, including query string, as the sole resource descriptor; use the request body only to contain new information. I get a bit tripped up over what I understand to be Roy Fielding's objections to maintaining state through cookies - I continue to do that, but with a vague feeling of unease that I'm missing something.
It's ok to have client state in cookies, just not application state.
For instance if you have a shopping cart you can have "items in cart" in a cookie because that's pure client state. You can think of the client as a resource and, say, a "view cart" page as a representation of that resource.
If the cookie in any way tells the application how to behave, then you have sinned against the gods of REST. The most common example is probably the login redirection cookie.
Just store a session ID in the cookie and keep the client state on the server side, indexed by that cookie. No need to make a memory lookup into network transfer.
The problem is that REST only makes sense when your UI is all about data entry. Sure, it's great there. You update things, you create things, you delete things, you replace things. Wonderful stuff.
But as soon as your application steps beyond that, you're sunk. The user of a web application only rarely interacts directly with resources. Individual forms can be linked to multiple database objects or none.
What REST can't handle is any level abstraction between CRUD and UI.
REST doesn't tell you what to do with the information after it's created or updated. Everything you might want to do through a web interface can pass to the server through the narrow funnel of CRUD.
It might seem that an exception to that would be to initiate some action off the server: send a fax, send some emails... but you can also look at these instances as changing the state on the server such that such action is requested. It's then up to another process on the server to respond to the changes and update the state on the server to show the results of that action.
Oh, I agree with the exception statement. That sort of shoe-horning is exactly what goes on when you REST up a rich web-app. But how does it simplify anything?
REST is just using HTTP properly (as a transfer protocol) - if you want to implement RPC go use some other protocol that is actually a transport, instead of raping HTTP simply because it will get you through firewalls.
REST is a far superior approach to developing web apps because it actually respects the style of the underlying protocol. It's not that mystical or complicated.
Oh and stop using front controller patterns, they're stupid.
In fact, REST barely exists in the Django world. The problem that Rails solved with CRUD, Django solved with the Admin interface.