The problem is that “something I have” is generally supposed to imply that it’s a physical object whose functionality cannot be feasibly copied to another object. Some data, especially data stored in the cloud, isn’t really a good candidate, even if it’s protected by a password that only you know.
I disagree. The "have" factor can be soft or hard. It just needs to not be memorable (because then it's guessable, which is a primary weakness of a "know" factor).
For example: if you have an application protected by password+yubikey with "remember device" enabled, after prompting for your password it may decide not to also prompt you for the yubikey, and that can be because a cookie (perhaps ANDed with some other heuristics) is taking its place. A cookie which can be trivially copied to another device, but can't be trivially memorized nor guessed, and is for that reason not a "knowable" thing. If it was considered a "know" factor, then the "remember device" feature would effectively be a "conditionally disable 2FA" feature (two "knows" are 1FA), but it's really not that, outside of describing the interim UX.
I think that a "remember device" feature is a totally orthogonal concept. That's really just another word for a session, and it's quite common for authentication to apply to an entire session rather than to each and every message in a session.
It's true, of course, that once you have created an authenticated session on a device, anyone who has compromised that device (with physical access or a software hack) can likely gain access to that session. But the authentication method still prevents unwanted initiation of sessions, which is the whole point.
Any service provider obviously needs to choose their session policies to match the sensitivity of their service, their own threat models, and the threat models of their clients. So e.g. an online bank probably shouldn't issue cookies that last for a year and are portable across IP addresses. For some services, it could be a good idea for the session to only grant less sensitive access (e.g. only read access), and still require fresh authentication for sensitive actions (e.g. transferring money).