> I'd love to see numbers
This was an experiment, and I didn't do a performance test. The Orleans people will tell you that the current production version will process something on the order of a couple hundred thousand of messages per server per second. If your actors are modelled well, this scales to hundreds of servers, so it would be possible to have on the order of tens of millions of messages per second between actors, including persistence. I expect the upcoming Dotnet Core version to do even better.
> How's the testing/debugging experience
I normally test with xunit, standard dotnet stuff that works very well. Orleans provides a TestingHost that lets you spin up silos for testing grain code in a 'real' environment. This costs some time for startup.
The time travel idea needs some devtools ui, which I didn't build. I'm sure this would be possible though, with the limitation that the "edit and continue" feature of dotnet is not as capable as in javascript: often visual studio will tell you that your change requires a full application restart. You can change code and data while paused in the debugger.
> What happens when the machine goes down?
Orleans would respawn the Grain on another server (using the last-known state) and retry the operation up to two times by default. If you follow a safe implementation pattern (call WriteStateAsync after a state change), your state will be correct. In my blog code, I await successful completion of the message on the client. If something went wrong in Orleans and the state isn't persisted, that promise would be rejected, and it could be shown to the user.