Speaking only for myself as ever:
Handling out of memory errors is a hard problem. At the point when you can't allocate more memory you are busted in most languages. For example in C a slightly deeper function call depth can cause the stack to expand at any point. If that point coincides with you running out of memory then you are busted. No program can keep running with a broken stack.
If V8 were capable of recovering from out-of-memory errors then you would still have to go through all of node and all the native libraries that it uses and check that they can handle any allocation failing.
And if V8 handled out-of-memory errors with exceptions then you have two choices. Either make the exceptions uncatchable, in which case the JS program running in the server has no way to recover and is probably in an inconsistent state. Or make the exceptions catchable, in which case there is no guarantee that any memory will ever be freed up and you are back to square one.
I think it's possible to make V8 more resistant to out of memory situations. I don't think it's possible to make it bulletproof, and I don't think there are many server apps that have this property. Do people run Java servers in such a way that they are often getting out of memory exceptions, recovering, and then continuing to serve? I don't think so.
In practice the way most servers work is that you give them plenty of memory and you write your server app in such a way that it does not use unlimited memory.
If there are non-out-of-memory errors that V8 is failing to recover from then these are bugs and should be reported. I can't think of any examples off-hand.
As far as the other comments go they seem to assume that you will want to use a V8 context per connection. Node uses one V8 context for all connections, so the comments don't apply. Context creation has been speeded up a lot since the article was written, but this is only for the browser. Node doesn't need it.