The main problem I'm aware of with synchronous inspection is that it's completely unnecessary, unless your code relies on the promise resolving or rejecting within a certain number of ticks, which is exactly the sort of thing you should not rely on.
For instance, although I know nothing about React, I'm pretty sure your example could be changed into something like this:
this.text = "";
var promise = ...;
this.text = "Success: " + JSON.stringify(result);
this.text = "Error: " + JSON.stringify(error);
// render the current value of this.text
You could even argue this version is better decoupled because now the
render method has no idea that the value of
this.text depends on that one specific promise. You could now easily make
this.text depend on the results of several different promises chained together without causing a combinatorial explosion of synchronously inspecting if statements.
The only other argument for synchronous inspection which I'm aware of is that "it is known in certain code paths that a promise is guaranteed to be fulfilled at that point - it would then be extremely inconvenient to use .then to get at the promise's value as the callback is always called asynchronously." I would rather use
.then() even in these cases, because a promise is not really guaranteed to be fulfilled until you're in its
.then handler (or
.spread handler or whatever). Assuming otherwise just creates an obvious way for my program to break in the future, no matter how airtight my argument might be today. If the handler being called on the next tick is a serious problem, then you're already depending on how many ticks certain operations do or don't take to resolve/reject, which is something you need to fix properly rather than work around.