As a general rule, the server should not provide information about a submitted password, regardless of if that password was correct or not, back to the client.
After all, humans tend to reuse passwords, so even if the password isn't correct for that user on that site, it may be correct on a different site, such as their bank.
I'm not aware of any ways to intercept a password that applies only to receiving the password, that wouldn't apply to sending it as well. However, the fewer number of times a password crosses a network, the better1.
If the application submitting the password does a full page refresh, then the attempted password most definitely should not appear in the password field, because it requires the server to send that information back.
If, instead, the application submits the password through an AJAX request or some other means that does not update the page (or the login form), then it is safe for the password to remain in the field, as opposed to being re-filled in for you by any action from the server.
The only ways that I can think of that it might not be safe, is in cases where (potentially) malicious scripts are loaded after an authentication attempt. However, I consider such a vector to be unlikely and contrived, and the possibility indicates that the site itself is untrustworthy, regardless of when it loads the scripts. (Related tangent: Don't reuse passwords. Use a password manager and generate random passwords for every site; you never know when a site may be compromised (whether intentionally or not).)
The closest that the NIST standards on passwords come to making a judgement on this specific case, in section 184.108.40.206, says (emphasis mine):
In order to assist the claimant in successfully entering a memorized
secret, the verifier SHOULD offer an option to display the secret —
rather than a series of dots or asterisks — until it is entered. This
allows the claimant to verify their entry if they are in a location
where their screen is unlikely to be observed. The verifier MAY also
permit the user’s device to display individual entered characters for
a short time after each character is typed to verify correct entry.
This is particularly applicable on mobile devices.
A strict reading of this could be interpreted as clearing the password field every time it is submitted, whether using a full page refresh or using an AJAX request. However, it is part of a "SHOULD" statement, rather than "SHALL" statement. Regardless of how strict one interprets this, the entire standard seems to assume that submitted passwords are never repeated by the server.
1Quick side note: I see a lot of people suggest to send a hash of the password, rather than the password itself, to prevent it from going across the network. This doesn't improve security because when doing that, the hash becomes the password.