I've noticed that on many sites, when they ask for a one-time password (OTP) (usually sent by SMS), the input is hidden in the same way as a password field is.

My understanding is that once an OTP is used, then it is no longer useful for anything.

Is there a valid reason for hiding the input for these fields?

I'm basing my answer on the assumption that a One-Time Password is used as a second factor, in addition to a traditional username/password combination. If this is not the case, and the One-Time Password is the only factor, then Gilles' Answer is certainly more applicable.

Most likely due to Cargo Cult Programming, which means blindly following patterns that have been observed elsewhere, without understanding the real meaning behind them.

A developer may see the "password" in "One-time password" and happily make it <input type="password">. Afterall, that's what it's there for, right?

Is there a disadvantage?

Security-wise, no. Disclosing a one-time password to a third party (e.g. through shoulder surfing) is not as problematic, because the password loses validity after one use, or after a certain amount of time.

The only imaginable downside would be a lesser user experience, as a user might have trouble ensuring that what they have typed actually matches the password they received.

The reason to hide passwords is to prevent shoulder surfing: someone being physically present (or someone observing through a camera) might be able to read the password on the screen. This is also a risk for a one-time password, but to a much lesser extent for two reasons: the one-time password is only valid for a short time, and it's displayed on the OTP device anyway. But it's a risk nonetheless. Depending on the type of OTP, it may remain valid for a couple of minutes (if it's time-based and the server doesn't protect against replay) or until the legitimate user has finished typing it (if it's sequence-based or the server protects against replay). Often the screen of the OTP device is less visible to shoulder surfers than the computer where the user enters the OTP.

Declaring a field as a password does other things than hiding the data: it may prevent copying to the clipboard, and may cause the application not to record the OTP in a form entry history. None of those has any security benefit, but omitting the OTP from the entry history has a usability benefit: it avoids giving users the impression that the OTP is a valid input later.

These are pretty weak reasons. The main reason is that form designers see that the input is a password of some kind and therefore declare it as a password.

Speculating about the motive of other developers is perhaps a poor use of time, but I can see one advantage that hasn't been mentioned.

Psychologically, making it look like a password helps people associate it with security. It transfers the message we have pushed for decades that "you don't tell people your password" to OTPs, and hopefully helps a few more users pause and question when Bob Hackerman phones them up asking them to confirm the six digit code he just sent them. The user is usually the weakest part of the system, so that seems like a reasonable place to invest.

Technically, there are disadvantages (like the browser storing it) and it would be better with a dedicated HTML field for OTPs. Even if we had one, it would be entirely reasonable to have it dotted out as the default UX.

The reason for hiding the input of the field maybe due to programming patterns (like @MechMK1 stated), because the developer wouldn't code a separate field for each authentication type offered so they reuse the field with type password. Not doing so could lead to code bloat.

An attacker could use the one time password when he sees you typing it in.

It comes down to the question of timing. If he is a sophisticated attacker he might read the not hidden one time password and at the same time block your network connection before you hit enter. So he can read the OTP you are typing, hinder you from sending the form and use the OTP to login as you.

This might sound very awkward, but in our opinion a sincere OTP implementation should take care of this.
As @MechMK1 pointed out the OTP is - as the name suggests - only valid once. But the OTP is only invalidated when the server verifies it. And as mentioned, if the attacker can prevent you from sending the OTP to the server the otp is not invalidated and the attacker can use this very OTP before you.