We wouldn’t be removing it unless there was something wrong with it. After all it is the only option with self hosting capability.
As for storing TOTP codes in a hosted password manager, it’s not ideal because it’s really reducing security to one thing - authentication to your password manager. Also we wouldn’t suggest storing once-use “backup codes” in there either.
For once use-backup codes I don’t store these on my devices. Something like a LUKS/VeraCrypt container on a few USB sticks or backed up offsite is enough. You could even attach the LUKS container to your password manager and that would not reach the filesize limit, after all the backup codes are only text files and there is no reason the container couldn’t be 50MB. That way even if access to your password manager was gained the encrypted file would still require a separate password. Obviously don’t store that password in Bitwarden, if you do that.
For convenience however I can see the reason why people might just use a password manager for storing TOTP codes. If you’re going to do that I would think about the value of such codes, for example I would not store a domain/email TOTP secrets in a password manager. It would be totally reasonable to have Aegis with those two things in it, while storing other less valuable TOTP codes in Bitwarden. The exported Aegis JSON file could be added to your LUKS container however for backup. Another good thing to add there would be your LUKS volume headers.
TOTP codes are not the strongest way to do MFA because they rely on a shared secret. FIDO based security such as using a security key is always the better approach because it provides attestation and doesn’t require the service to hold any private secrets, that makes it the “best” security.