The terminology is occasionally used with a more technical meaning in algorithms, so perhaps that's how it's being used here.

"Optimistic" often means "assume X, perform or calculate something, change the result if X turns out to be false".

"Pessimistic" often means "assume not-X, perform or calculate something, maybe change the result if X turns out to be true".

This comes up in other domains.

For example in compilers (and reverse engineering decompilers ;-) there are optimistic and pessimistic analyses.

An optimistic analysis might initially assume a particular variable has a specific value at a particular location, or a branch is always taken. Then trace through the program paths, using that assumption (which limits those paths). If it loops back to the location with a different value in the variable or different value for the branch condition, broaden the assumption and update the trace.

A pessimistic analysis might initially assume the variable at a particular location could have any value because it hasn't yet traced everywhere to find out the possibilities, or initially assume both directions at the branch could happen and include them both in the trace. By the time it finishes tracing all paths and values, those assumptions may turn out pessimistic and it can start pruning away unused options.

These two strategies can yield different answers, and for some analyses the optimistic strategy gives more accurate results than the pessimistic strategy.

So which one is more "real"? :-)

To be wildly pedantic, pessimistic rendering would then be immediately showing an error, only to later clear the error away if the request is successful.

I got thrown recently by an update log (powerapps solutions) which seems to do exactly this - an in-flight install/update is shown as a failure until it completes. Eventually figured out I should ignore entries with a null completion time.

It depends on your frame of reference. If the message succeeds then there will be a window (all else equal and no funny business in the networking, around 1/2 round trip time) where the UI displays the message as spinning when it has in fact been successfully sent. If your frame of reference is not whether the message has been successfully sent but whether you know for certain that it has been successfully sent then I think you'd be right to call it "realistic rendering", but from the message's frame of reference "pessimistic" isn't a bad choice of words.