Once I understood the model, I did stop thinking about concurrency per-se, in the sense that I stopped worrying about threads and locks. I still have to worry about state, because its my responsibility to *not* schedule simultaneous writes to the same memory, but this scheduling is *much* easier to reason about than before. I suppose in this sense, I am thinking about coordination and not concurrency. Although I get rather nice core utilisation for 'free'.
Programmers unfamiliar with the CCR are often scared off by the perceived implications of a message-passing model. But the CCR's lightweight model is still very efficient, and whilst the straightline traditional model might be a few percent quicker, but I'll take the CCR most times because in the long-run I personally get a better overall result, not just in terms of performance, but also failure handling, robustness, scalability and clarity. And even if you just used it to introduce some asynchronous I/O into your app, you'd be amazed the difference that alone can make.
Interestingly, where you do still have to think about threads, locking, blocking etc, is around the boundaries where you are communicating with some non-compatible api/threading model, say COM, or WinForms/WPF. I don't know when (if ever) the user interface will move away from a model of thread-affinity, but on the client-side I think there's always a bit of a jarring switch between CCR and UI. It's doable but not entirely satisfying.
On the point of failure, as soon as you move to an asynchronous message-passing model, you pretty much can't assume that your message will even be delivered, (b) it will be delivered correctly or within time constraints, (c) the object will handle it correcly, (d) any response gets delivered (e) any response get's delivered within time constraints. You can ignore any one or more of these conditions, but you're system will live-lock pretty quickly if you're only ever waiting indefinitely for the successful response. The CCR model makes you consider these possible failures, but through its arbiters and causalities gives you the mechanisms to deal with them. And this leaves your code in much better shape when you really physically distribute because you're prepared for the much more likely scenario of timeout and network failure.
The final point I'd make is kind of related to mash-ups. While the asynchronous message-passing actor/agent model is a good approach for composing distributed systems from a 'temporal' perspective, from a functional perspective, surely mash-ups work because the operations you can perform against the various data sources (basically GET and POST) are relatively simple, uniform in their behaviour and well understood. Some are even actually RESTful . The DSS model, that sits above CCR takes a similar view of distributed state manipulation. It would be good to get a Going Deep on the DSS to the same extent that we've seen on the CCR itself, because just using CCR to make your SOAP/WSDL clients/servers more efficient, isn't going to make them more composable.