• the REST architectural style in general and REST implementation using web standards (HTTP, AtomPub etc.) in particular brings a lot of benefits in integration (what easy for humans to understand is easier to implement).
  
• Another reason for REST (over HTTP) is standardization over languages and platforms. Any language and platform I've used has an implementation that allows sending and receiving HTTP messages. We have few components running on Linux and components running on Windows and we're planning even more heterogeneity down the road.
• Lastly, REST allows for easy debugging and run-time interaction. This proved invaluable during system integration test where we could easily understand the current state of each of the components in the system as well as the general picture.

Ok, if everything is so good, why not use REST for the whole system? Well, because like any architecture or architectural style (especially, when incarnated in a technology), REST has things that it does well and things that it doesn't (personally, I don't buy the Only Good Thing(tm) for anything or as Brooks puts it there's no silver bullet).
Let's look at message exchange patterns for instance. REST over HTTP support the request/reply pattern.
This works extremely well in many business situation. For instance is we have an Order service (or resource for that matter) and we need to calculate the discount for a specific customer we can go to the Customer service and get her current status and check if she a VIP customer, senior citizen etc.
There are, however, places where it doesn't work as smoothly. Returning to our Order, lets consider what happen once the order is finalized and we need to both start handle it (notify the warehouse?) and Invoice it
The order service does not care about these notifications it isn't its business.
My favorite way to solve this is to introduce business events (incorporate Event Driven Architecture) so that the interested parties will get notified. Another common way to solve this is to introduce some external entity to choreograph or orchestrate it (BPM etc.) both options have different constraints and needs compared with REST. In my organization we have a lot of processes that lend themselves to event processing much better than they do REST over HTTP (though the implementation might end up aligned with the REST architectural style - I am not sure yet)

Another reason not to use REST is when you have to integrate with stuff that isn't RESTful, for instance we need to integrate with systems that use RTP and other such protocols so we are bound to that - and we are a startup with "green field" development. In an established enterprise the situation is much more complicated.

To sum up, in my opinion when you take a holistic view of a complete business you are bound to see places where different architectural principles are a good fit. Architecture styles (and architectural patterns) are tools you can use to solve the challenges.There are places where a hammer is a great fit, but it is also wise to make sure the toolset has more than just a hammer.

PS

It isn't that you can't do events with  REST over HTTP. e.g You can implement the events as an ATOM Feed and have the "subscribers" check this feed every once in a while (the way this blog works). It can even check the HTTP header before getting the whole feed. Still push is a more natural implementation for this for various reasons like you don't have to know where to find the event source and you can more easily improve latency (when needed) etc.