Re: The only way is OATH
OATH is fine as a second factor but it lacks enough security to stand on its own. It's easily for TOTP to fall to a machine-in-the-middle attack. HOTP looks fine theoretically, but the re-keying after failure is deeply problematic.
Having written this, OATH TOTP is far better than nothing, SMS codes, or an 2FA app. There's some fine clients, not just Google Authenticator. For example, andOTP has no Google-derived code but was written from the specification.
I'd recommend that people look into a secure hardware token. One which does FIDO/U2F for second-factor authentication, FIDO2/Webauthn for account authentication, and does HMAC-SHA1 Challenge Response for securing password databases. Yubikey are the dominant company in this space, but there's a handful of alternatives.
The hardware token provides key material for the password database. Maybe mix that key material with a trivial password so that a lost key can't be used immediately. The result is strong: the token challenge-response and password generate the key material needed to decrypt the password database, and the password database contains maximal-length, actually-random passwords for the websites which need passwords. KeePassXC provides a good implementation, but there are plenty of alternatives.
When configuring websites for FIDO/U2F second-factor authentication be careful to disable weaker 2FA alternatives which the website may also offer, such as SMS codes.
Finally, note that OATH's MITM shortcoming when compared with hardware tokens isn't always a weakness. I use OATH for some accounts as I may need to share the account (eg, some vendor websites only allow one account per client company) or where I may need to read the code over the phone for someone else to log into the account. For those accounts OATH provides better protection than a password alone.
Biting the hand that feeds IT
