TOTP is fairly weak. Convenient, but weak, due to the shared secret. I've seen proofs of concept that trivially lift the secrets from Google Authenticator. On the server side, the service is probably storing your TOTP secret one column adjacent to your hashed password. When done poorly (and most are), TOTP is basically no additional factor. Also backup codes, app specific passwords, etc, etc.
Certain classes of non-shared-secret hardware token are waaaaaaaaay better. Just less convenient. You should look into DoD CAC, for example. Google Authenticator is nice but will never protect Secret information. I know this sounds way out of startup league, but it shouldn't; we should instead study what we can learn from such things instead of blanket advice like yours.
The thread model TOTP addresses is someone having your password and being able to log in with just that. It's not to protect against people stealing the database, it's not to protect against people having root access to your phone, or anything like that.
Which of the solutions you mention works even if an attacker has actual physical access to the two-factor device?
> When done poorly (and most are), TOTP is basically no additional factor
TOTP protects against the most common threats, and is trivial to implement compared to other solutions you refer to.
Most of your complaints about TOTP security don't make sense under its threat model. Yes, if your phone is rooted, the TOTP secrets can be stolen. The point is that it's unlikely that both your phone and your laptop/point of access device both get compromised.
Certain classes of non-shared-secret hardware token are waaaaaaaaay better. Just less convenient. You should look into DoD CAC, for example. Google Authenticator is nice but will never protect Secret information. I know this sounds way out of startup league, but it shouldn't; we should instead study what we can learn from such things instead of blanket advice like yours.
Reiterating: none = bad, TOTP = better, strong tokens/biometric/etc = best.