Good thinking. I suspect it's this. During the /finalize/ request, we write to the database primary, then tweak the in-memory Order object to add the certificate serial and set status to "valid" before returning it to the user.
On polling the order, we query a read-only replica. That could be lagged behind the primary, in which case you'd see an order in "pending" state with no certificate URL.
So, I'd be very surprised to ever see an order with "valid" status and no certificate URL. But a situation where /finalize/ returns a "valid" order but subsequent polling gives a "pending" order again is very plausible.
It would be more consistent to have /finalize/ always return a "pending" order, and require subsequent polling to see the order become "valid". This is the intent behind our AsyncFinalize feature flag, which we've tried turning on in the past; but too many deployed clients had trouble with it.