For whatever reason, quite often you can only register a single device (looking at you AWS Root account). The only way around this is by setting up your backup keys with the same OTP private key and use the Yubico Authenticator app to generate the TOTP.
For WebAuthn (and thus FIDO devices) this comes up regularly on HN. It's just AWS. It may feel like it's "everywhere", because it's your Amazon Web Services account, the credentials you use with DynamoDB, the thing you need for your EC2 VMs, the Cloud Computing stuff, your S3 buckets... oh right, yeah, that's all actually just AWS isn't it.
It's still a bug, but it's specifically a bug in Amazon's implementation, there is no wider ecosystem problem here.
In general, most platforms don't really account for the scenario "my 2nd factor got stolen/robbed/destroyed/lost" beyond also offering a phone app and printed recovery records - and the end result is that a house fire, flood or storm scenario locks out users permanently.
Don't know about Dropbox, but I set up Yubikeys for Twitter, Google and Facebook recently and they all allow multiple keys.
Just yesterday I discovered that Thinkst (Canary Tokens) only lets you register a single webauthn token. Thinkst is a company that makes security products! I'm expecting to see this more as adoption picks up.
As to the larger point, as well as explicitly telling you to support multiple tokens, WebAuthn is designed in a way that makes the "one single token" implementation pretty unergonomic, which you'd hope would cause anybody who isn't just copy-pasting to think "Huh, I wonder why I need a list of exactly one item here, and this other array with exactly one thing in it, and I have this database table with a column I never use for anything. What a strange design unless... oh right, yeah, we are explicitly required to support multiple tokens".
For example, the tokens have a mandatory ID for each enrolment. It's huge (larger than a UUID)! If you're never allowing multiple enrolments it might seem tempting to just forget the ID. There's only one per user, so it's not a problem right? Nope, now nothing works. Cryptographically this now can't work because the ID - while yes it's an identifier and you can totally use it as a PRIMARY KEY in your database or whatever - is also critical to the cryptographic underpinning and so if you've lost it now you can't do WebAuthn.
It is of course possible to get it wrong, not really any way around that, but I don't think it's often going to happen by mistake rather than policy.
Their paid service which has user accounts can be found here: https://canary.tools/
To your larger point, I hope you are right. But I know I've worked with people in the past that given the task to add support to webauthn would (a) not bother to understand it more than the minimum copy paste examples from stack overflow or from a webauthn library and (b) would feel like adding a new SQL table to store store these would be "a lot more work" and "the jira ticket didn't say we needed to support more than one per user."