AFAIK, the "scan this QR code" method of signing in with a passkey on a phone on a device w/o the passkey requires Bluetooth. There's some type of handshaking that goes on in order for you to prove you're in physical proximity of the device you are logging in on, to prevent phishing attacks.
Since I might have made someone mad... to clarify, as I understand it, Bluetooth is absolutely required for this "Scan the QR code" flow to work. However, it's also possible the actual authentication traffic to travel over a different pathway (wifi, cellular), but the bluetooth part is always required though to prove proximity. So on e.g. a library computer without Bluetooth enabled, you would not be able to log in with a passkey on your phone.
Right - you can treat the protocol as having:
1. Initiation (QR code, NFC in draft)
2. (Proximal) negotiation (BLE key exchange)
3. Communication (over websockets or a direct L2CAP channel)
The challenge is that a devices without bluetooth (at least today) don't have another common way to wirelessly judge proximity. A desktop/laptop without bluetooth likely either doesn't have NFC, or has bluetooth disabled by policy and would likely have cross-device passkeys disabled by policy as well.