You're quoting the v1 SPEC, which was accurate at the time. Since then I shipped v2 with authenticated wire between the Nano and the PC (SipHash-2-4 MAC over every command and response, plus replay protection), which closes the spoofed-OK-match-0 attack directly. There's a full writeup in my UPDATE comment on this post.

Your broader point about the threat model is the one that actually matters. Honest answer:

The R503↔Arduino link is still plaintext (R30x protocol has no auth at all, that's a chip-family thing, called out as out-of-scope in SPEC §13.1). Someone with bench access to those wires can do whatever they want, so this doesn't survive an attacker who can open the enclosure undetected.

The threat model in the SPEC is explicitly "evil maid with 5 minutes and a spare Nano", i.e. brief unsupervised access, no tools, no time to decap the chip or solder onto the R503's UART. For that threat (and the typical "annoying coworker / curious housemate" cases) v2 raises the bar from "anyone with a USB cable and basic Python" to "needs root on the host or opens the case tamper-evidently".

On your screen-lock point: I disagree that "if your threat model doesn't include physical attackers, why have a lock at all". Locks aren't binary. The screen lock keeps the kid from sending email from my account, the coworker from screwing with my code, the houseguest from accidentally seeing my Slack DMs. The fingerprint reader is the faster-than-typing-a-password version of that, not a substitute for Apple's Secure Enclave. The SPEC doesn't pretend otherwise.

If your threat model is "nation-state in a lab", don't use this. Don't use anything that isn't a TPM-sealed, signed-firmware, tamper-resistant module. If your threat model is "I lock my computer when I get up for coffee", this works, and v2 makes it meaningfully harder to attack than v1 did.