My rule of thumb is quite easy - use exceptions for exceptional situation. If all variables outside scope of application (filesystem, network, memory, user input etc) are correct, no exception should be thrown. Of course, it is sometimes not possible, but for me it is a goal which helps me to decide when use exception and when do it 'manually'.
Basically that's exactly what I meant by 'where applicable', I was just a bit vague
The cases where I use exceptions are the cases where it won't matter much if an exception is costly or not, 'cos those are the cases where we're screwed anyway
In the really performance critical parts, I don't even want to be checking data if possible in order to see what kind of ResultObject I'd want to return at all.
So, for example in Cosmic Trip exceptions might be thrown at start up, shut down, sending a high score to the server, fetching the high scores from the server or handling a complete crash for cases I didn't see coming (so that the game shuts down when something occurs I didn't see coming).
But, if you really demand more exceptions to be handled in your performance critical part (the running game I imagine), something like ResultObject you described might be cheaper than exceptions *if an exception would be thrown*.
OTOH I can imagine checking your data constantly to return a proper ResultObject every time could even cost you more in the case an Exception would *not* be thrown, which is what 'normally' would be the case.